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Chapter 1. Introduction 


Note to the reader: because you are reading 
this manual, you must have already received 
sufficient proof of mTropolis’ value to you 
and your work. Just to make our marketing 
people happy, here is a restatement of what 
the core value of mTropolis is: it helps you 
build better titles, faster, propelled by better 
collaboration between you and your coworkers, 
that perform superbly on the platforms likely 
to be in people’s homes or offices. mTropolis 
is also totally extensible, so if you can’t do 
something in mTropolis “out of the box,” you 
can buy or build components that seamlessly 
extend mTropolis in the manner you desire. 


mTropolis is a true multimedia application 
development environment that produces 
stand-alone, platform-optimized titles. De- 
pending on the richness of the media you 
want to incorporate, a mTropolis title can be 
deployed on CD-ROM, floppy disks, hard- 
disks, on-line systems, or any combination 
thereof. Platforms currently supported by 
mTropolis for title deployment include any 
Macintosh or Power Macintosh (native) run- 
ning System 7 or later, and any Windows 3.x 
or Windows 95 machine. mTropolis, the de- 
velopment environment itself, runs on Mac- 
intosh or Power Macintosh (native) 
machines. Versions for other platforms are on 
the way. 


What distinguishes mTropolis from other de- 
velopment environments is that it compro- 


mises neither accessibility nor performance. 
While it is considerably more approachable 
than Visual BASIC or Director, mTropolis 
produces titles with performance that would 
impress even the hardest-core Visual C++ or 
MetroWerks user. At the same time, titles can 
be developed, tested and debugged interac- 
tively inside the mTropolis environment. 
Without lengthy compile times and while still 
providing complete debugging information 
about every process occurring within your ti- 
tle, mTropolis offers true incremental devel- 
opment of very sophisticated titles. 


This incremental development process has 
been designed from the ground up to be 
equally inviting to both dedicated program- 
mers and creative talent. An artist or produc- 
er can immediately begin moving media 
objects around the screen of the mTropolis 
environment, crafting layout, appearance and 
relationships without a line of script or code. 
Programmers can work through complex 
problems in a framework designed to manage 
complexity without imposing development 
metaphors. Many programming problems, 
ranging from sophisticated collision detec- 
tion systems to very large state machines, can 


be created without a single line of code. Pro- 

grammers and artists can integrate each oth- 
ers’ work at any time, independently of each 
other, in evolutionary steps, without having 
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to commit to a massive final production pro- 
cess. 


The Developer Guide describes the mTropo- 
lis environment in relation to other develop- 
ment models, and it provides an 
understanding of various design approaches 
to multimedia programming problems. The 
guide also provides a conceptual overview of 
the mTropolis framework, which is founded 
on an object-oriented, message-passing core 
technology called mFusion™. This guide will 
focus on the “citizens” of mTropolis — the 
various objects that mTropolis provides for 
your use; the hierarchies for objects that pro- 
vide structure to help manage complexity; 
and the messages that connect mTropolis ob- 
jects together into a dynamic, unified title. 


The Developer Guide is targeted at multime- 
dia developers, programmers, designers, pro- 
ducers, project managers and creative 
professionals. We are assuming that readers 
have had some exposure to interactive multi- 
media development including media types, 
media creation and conversion, and a funda- 
mental understanding of the development 
process. 


CONVENTIONS USED IN THIS 
MANUAL 


Illustrations have been included to help you 
find specific information quickly. 


Step-by-step instructions are shown as bullet 
text. For example: 


* Choose Open from the File menu. 


* Select the graphic tool in the tool palette. 


The names of menu items, buttons, check 
boxes and radio buttons are capitalized and 
set in bold type. For example: 


¢ ...the Duplicate menu item... 
e ...the Cancel button... 


The names of messages, dialogs and text 
fields are capitalized. For example: 


* ...the Modifier’s Name field... 
¢ ...the Element Info dialog... 


The names of commands are capitalized and 
italicized. For example: 


¢ ...sends a Play Forward command. 


For keyboard shortcuts, the command key is 
written as “3”. 


Conventions Used in this Manual 
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Chapter 2. mTropolis Interface 


This chapter provides an overview of the 
mTropolis interface. When you start mTropolis, 
a window appears with pull-down menus, 
scroll bars, pop-up menus for quick naviga- 
tion around a work in progress, and a variety 
of floating palettes (Figure 2.1). This window 
represents an untitled project. A project is the 
conceptual framework in which your work 
on a multimedia title takes place. For all in- 


tents and purposes, a title and project are syn- 
onymous. You can work on multiple projects 
simultaneously: each project occupies a win- 
dow like the one described above. 


OBJECT MANIPULATION 

Every action in mTropolis, except very special- 
ized, global operations (like saving a title ver- 
sion of your project) can be accomplished 


é @ File Edit Format Arrange Object View Window 


Untitled Graphic 


Untitled-1 : Layout 


fa 
Untitled Section || Untitled Subsection || Untitled Scene y|le#| >) 


ad 
az 
fs] 
Fol! 
aa 
ia 
Be 


Figure 2.1 The layout window with tool and modifier palettes 


Object Manipulation 
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with direct manipulation. To illustrate, the 
internal operations of mTropolis objects can 
be configured by double-clicking on them. 
Portions of a mTropolis project can be rear- 
ranged, or even moved to a different project, by 
dragging and dropping. The pull-down 


menus in mTropolis provide access to spe- 
cialized operations such as opening files or 
linking media assets, as well as many of the 
operations that are available through direct 
manipulation. 


mTropolis has been designed with careful at- 
tention to user interface consistency. If an ob- 
ject on-screen can be clicked on, it can be 
dragged and dropped somewhere meaningful 
and will provide helpful feedback about its 
role in its new home. Any object on-screen 
can be double-clicked, and it will, at the very 
least, bring up a dialog that conveys useful in- 
formation about its internal workings. Gener- 
ally, this dialog can be used to reconfigure an 
object as well. 


This consistency means that you can experi- 
ment with mTropolis, incrementally applying 
knowledge that you gain to new tasks, with- 
out frustration. You can concentrate on learn- 
ing techniques, not interface details, and the 
consequent short learning curve puts more 
power into your hands more quickly. 


TOOL AND MODIFIER PALETTES 
mTropolis provides a variety of palettes to 
keep development resources readily at hand. 
The modifier palettes included with mTropo- 
lis provide quick access to mTropolis objects 
that you can drag and drop in the process of 


building a title (Figure 2.2). A tool palette of- 
fers the tools most frequently used in build- 
ing and manipulating the constituent pieces 
of a mTropolis title. 


Figure 2.2 Modifiers can be dragged and dropped 
onto elements 


Other palettes provide similar productivity in 
managing more sophisticated aspects of the 
mTropolis development process. For exam- 
ple, the asset palette provides a view of all of 
the media assets used throughout your 
project. Even if a media asset has already 
been used in your project, it can simply be 
dragged off the asset palette to be used again 
in whatever section of the project you are 
working on. Also, the asset palette is automati- 
cally updated whenever you link new media to 
your project. 


mTROPOLIS VIEWS 

mTropolis offers three primary views of your 
work, each of which allows you to edit and 
manage your project in different ways. The 


Tool and Modifier Palettes 
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Chess Game : Layers 


a 


Shared Scene 


queen.pict 


Untitled Scene 


pawn.pict 


Figure 2.3 The Layers view 


layout view (Figure 2.1) allows you to directly 

manipulate the graphical aspects of your title 
in WYSIWYG fashion—arranging objects, al- 
tering their appearance and so forth. The lay- 
out view is described in detail in Chapter 9 of 
the mTropolis Reference Guide, “Layout Win- 


” 


dow”. 


The layers view (Figure 2.3) shows you all of 
the constituent graphical pieces of your 
project in their spatial order—what is be- 
hind, or in front of what else—and allows 
you to rapidly rearrange this order by drag- 
ging and dropping. The layers view is a sim- 
ple matrix, with each row representing a 
successive layer in the drawing order for a 
single subsection. The first column repre- 
sents the shared scene and the elements it con- 
tains. Each additional column represents an 


Libraries 


individual scene and the elements that it con- 
tains. The layers view is described in detail in 

Chapter 10 of the mTropolis Reference Guide, 
“Layers Window”. 


The structure view (Figure 2.4) presents an 
expandable/collapsible outline that mirrors 
the logical hierarchy of your project. This 
view shows what objects are contained within 
others — and allows you to rearrange this hi- 
erarchy at will by dragging and dropping. 
The structure view is described in detail in 
Chapter 8 of the mTropolis Reference Guide, 
“Structure Window”. 


LIBRARIES 
mTropolis offers a very powerful facility for 
managing large projects, enabling collaboration 
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Figure 2.4 The Structure view 


and promoting reuse of project work. This fa- 
cility is called a library. mTropolis libraries 
can contain any mixture of objects, media as- 
sets, or the structure in which objects and 
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media are embedded. Multiple libraries can 
be open while you are working on a project, 
and you can freely drag and drop to and from 
libraries. Libraries are described in detail in 
“Creating and Modifying mTropolis Librar- 
ies” on page 2.3 of the mTropolis Reference 
Guide. 


DEBUGGING SUPPORT 


Last but not least, mTropolis offers thorough 
debugging facilities. The primary mTropolis 
debugging facility is called the Message Log 
window (Figure 2.5). As mTropolis is an ob- 
ject-oriented system, the flow of a mTropolis 
title is determined by messages exchanged in 
conversation between mTropolis objects. The 
message log provides a complete, contextual 
history of every message that was exchanged 
between objects, including those that are user- 
generated. The message log is described in detail 
in “Message Log Window” on page 7.3 of the 
mTropolis Reference Guide. 


Figure 2.5 The Message Log window 
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The mTropolis development environment is 
object-oriented. That is, you use mTropolis 
to create a multimedia title out of a set of co- 
operating software “objects”. Using objects to 
create a title is like building a race car from 
Lego blocks; you can build something very 
sophisticated from simple parts that snap to- 
gether in a clear and understandable fashion. 
Conversely, the old ways of creating a title 
were like trying to write a Shakespearean play 
in Latin; you had to laboriously script every 
potential action, step by step, in a language 
with which you might not feel too comfort- 
able. 


mTropolis does not impose any particular de- 
velopment metaphor upon its users. Artists 
and programmers can create, manipulate and 
evolve any combination of media and logic 
without being constrained by an abstract, lin- 
ear paradigm, such as creating “frames” of a 
movie. This freedom permits groups of artists 
and programmers to collaborate without pro- 
cedural bottlenecks. Once the title is devel- 
oped, its constituent objects can interact 
under the control of any combination of time, 
internal decisions, or external user-generated 
events. This characteristic of mTropolis titles 
allows them to more closely model the real 
world, with many different events of different 
types driving the title experience in truly nov- 
el directions. 


Objects and Messaging: a Definition 


This chapter introduces the concept of ob- 
ject-oriented design. Chapter 4, “mTropolis 
Basics”, shows how the design approach is 
implemented in mTropolis’ authoring envi- 
ronment. 


Any programmer or author comfortable with 
object-oriented programming (e.g., experienced 
with C++, SmallTalk, or ScriptX), can skip 
this chapter except for “Components and En- 
capsulation” on page 3.4. 


OBJECTS AND MESSAGING: A 
DEFINITION 

mTropolis’ design approach requires some 
background information because it’s an en- 
tirely new way of working with the content of 
a multimedia title. 


Software objects are a way of structuring 
computer software to work more like the real 
world. In the real world, a hammer and a 
clock are objects. Most everyone knows how 
to use them, and no one mistakes them for 
each other (except perhaps Salvador Dali). 
Software objects act literally as the software 
counterparts of real-world objects: they mod- 
el the real-world objects and the interaction 
of those real-world objects inside the com- 
puter. 


In the real world, it is clear what you can do 
with a hammer. For example, you can pick it 
up or swing it. It is also clear what you can 
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use a hammer to do. For example, you can 
use it to drive a nail into a wall. What you can 
do to or with a real-world object could be 
called its capabilities. A hammer is capable of 
being swung, and it is capable of driving a 
nail into a wall. Real-world objects also have 
properties. Properties are intrinsic features of 
a real-world object, like its height, weight or 
color. An interesting example is that of a 
clock, which could be described as having the 
“property” of time. 


A software object models a real-world object 
by duplicating as many of the real-world ob- 
ject’s capabilities and properties as appropri- 
ate. A software object modeling a clock might 
present an image of a clock (with color, 
height and weight properties), as well as have 
code to keep the time (a clock’s time property). 
Thus, software objects come much closer to 
representing the autonomous, rich real-world 
objects from which compelling experiences 
are derived. 


An important point about software objects is 
that they can represent capabilities or proper- 
ties that are abstracted from a complete real- 
world object. For example, a software object 
might keep track of time, but not have the 
other, visual attributes of a clock. Such an ob- 
ject would be a timer software object. By 
combining such objects that implement ab- 
stractions with objects that model more tan- 
gible attributes, you can create very 
sophisticated real-world—and more impor- 
tantly, unreal but still coherent—models. For 
example, you could combine many timer 
software objects with other, more visual ob- 


jects to create a many-faced clock object. 
Now, consider that you could add an object 
with the abstract capability of movement to 
create a flying, many faced clock. 


In the real world, objects interact directly. 
You grab a hammer, or glance at a clock. In 
the unreal world of the computer, software 
objects interact through messages. Messages 
are the mechanism by which software objects 
make use of one another’s capabilities or dis- 
cover the state of one another’s properties. A 
software object representing a person would 
send a message to a hammer software object 
in order to pick it up. A timer object will di- 
vulge the state of its time property when it re- 
ceives a message telling it to do so. A message 
sent between two objects is like a very fast, 
structured e-mail message: it contains infor- 
mation about the sender, the receiver and 
what the receiver is supposed to do. 


Software objects, although they have the 
same benefits of simplicity and easy intercon- 
nection as do Lego blocks, have other advan- 
tages. Because they are simply pieces of 
software living in a computer’s memory, they 
can be arbitrarily created, destroyed, dupli- 
cated, renamed, reconfigured or otherwise al- 
tered. 


Design Example: Objects vs. Procedures 
An analogy may help to make the design issue 
more apparent. Imagine a program designer 
who wants to model the activities of taxis ina 
city. Using a procedural programming tool 
that requires scripting, the designer creates 
the map of the city and then must define, in 
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advance, all the possible paths that the taxi 
cabs will be allowed to follow as well as all the 
conditions under which the taxi cab stops, 
starts, breaks down, runs a red light, runs out 
of gas, takes on passengers and so on. With- 
out programming that challenges even the 
most seasoned of professionals, it is not pos- 
sible for the taxis to behave in truly novel, in- 
teractive ways. 


Using a procedural model, the more dynamic 
the simulation, the more difficult and time- 
consuming the program coding becomes. 
Programs that use the procedural (scripting) 
method act like a taxi dispatcher who has to 
tell all the cabs exactly where to go, when to 
stop for gas and what to do as the simulation 
unfolds. To illustrate, if there is a request for 
a cab from a hotel in the city, the dispatcher 
has to query all the cabs to see if there is one 
that is available, then must calculate which 
available cab is the nearest to the hotel. If the 
cab is just about to run out of gas, it must be 
“flagged” as unavailable. 


In object-oriented programming languages, 
the designer lays out the city and creates “taxi 
objects.” The taxi objects are embedded with 
the instructions about where to go and what 
to do. They have their passenger status, and 
location, and gas gauges built into them. In 
this model, if a passenger calls for a taxi, the 
taxis with full tanks and no passengers listen 
for the message, measure their distance from 
the hotel and the taxi closest to the hotel 
picks up the fare. 


Although it is certainly possible to model the 
complex interactions of natural processes in 
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procedural languages, the more complex the 
interactions in the program, the more com- 
plex and inflexible the structure of the program 
becomes. Given that complex interactions are 
the heart of truly compelling new media ti- 
tles, procedural languages are merely road- 
blocks to your productivity. The bottom line 
is that in object-oriented models, objects take 
care of themselves, leading to not only greater 
productivity but greater realism as well. 


There are other significant productivity ad- 
vantages to object-oriented approaches, 
which we'll discuss below. 


Design Changes 

Although the message-passing that occurs in 
object-oriented programs can be complex, 
object-oriented design is much more flexible 
and responsive to design changes. 


For example, ifa design change is introduced 
to the taxi simulation, it has a much greater 
impact on a procedurally-constructed program 
than an object-oriented one. If a decision is 
made to set the city in the 18th century rather 
than the 20th century, the simulation devel- 
oped with an object-oriented tool would not 
have to be radically changed. The image 
property of the taxi could be changed toa 
horse. Tweak the gas gauge to be a “hay 
gauge,” set a different value for “horsepower” 
(literally!) and cars are replaced by horses. 


Reusable Code 

The ability to take existing intellectual or cre- 
ative effort and arbitrarily reapply it to some 
new need is a major productivity benefit of 
object-oriented systems. 
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For example, if the designer of the taxi cab 
simulation decides to include trucks in the 
simulation, the behavior of the taxi cab can be 
duplicated, slightly altered to suit that of a 
truck and added to the simulation. The taxi 
cab code has literally been reused to create 
truck objects. 


Inheritance and Building Complex Objects 

The rapid creation of sophisticated entities 
from simple constituent objects is another 
substantial productivity benefit of object- ori- 
ented systems. Complex real-world systems 
can be modeled much more easily than with 
any other approach. 


When discussing this concept previously, the 
analogy of snapping together simple Lego 
blocks into a more sophisticated entity (such 
as a race car) was employed. The race car “in- 
herits” the capability of the motor block to 
spin a drive-shaft, and it “inherits” the 
strength properties of each block. Similarly, a 
clock object in an object-oriented world can 
inherit its ttme-keeping capability from an ab- 
stract timer object. One of the major benefits of 
inheritance is that if the inherited object 
changes, its “heir” acquires that object’s capa- 
bilities or properties. For example, if the ab- 
stract timer object is changed to have 
millisecond precision, the clock object now 
can keep time to the nearest millisecond. 


Components and Encapsulation 

Advanced object-oriented systems such as 
mTropolis provide more transparent reus- 
ability than that described above. This trans- 
parency is derived from objects that act as 
totally autonomous components, truly like 


Lego blocks. Standard object-oriented sys- 
tems (such as C++) do not provide such “plug 
and play” objects; some knowledge of their 
inner workings is always required to use 
them. 


Autonomous components depend on a feature 
of object-oriented systems called encapsulation. 
Objects “publish” what capabilities they will 
employ on behalf of other objects, receive 
messages invoking those capabilities and 
send back the results. Thus, they need not 
ever have knowledge of each others’ internal 
specifics. Therefore, those internals—both 
the data that an object operates upon and the 
code that does the operations—can be “en- 
capsulated,” or hidden away. Encapsulation 
eliminates dependencies between objects that 
prevent rapid enhancement of individual ob- 
jects, and allows objects to act as truly inde- 
pendent components. 


Components can be reused in any context, 
without the user having to understand any- 
thing about their internals. For example, a 
crow component used on the bleak Scottish 
heath of a murder mystery title can be placed 
in a children’s title. It will still caw and flap 
about its confines without any modification, 
tweaking or other effort on the part of the us- 
er. Thus, artists can use extremely powerful 
components without any programming 
knowledge. 


There is one important distinction between 
mTropolis and low-level development envi- 
ronments such as C++. In mTropolis, the au- 
thor combines components and connects 
components in conversation, to create so- 
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phisticated entities that themselves are build- 
ing blocks for titles. This approach eliminates 
the tremendous, detail-oriented drudgery of 
C++ or SmallTalk. However, mTropolis does 
not allow the direct modification of compo- 

nent internals at the author level. 


The good news is that mTropolis provides a 
comprehensive set of programming interfaces 
(APIs) called mFactory Object Model 
(MOM). MOM permits someone like a casual 
XCMD writer to happily modify or replace 
any of the mTropolis components, and at the 
same time enables a serious C++ developer to 
alter or override all of the core systems in 
mTropolis itself. See “mTropolis Object Mod- 
el (MOM) User’s Guide” on page B.1 of the 
mTropolis Reference Guide for additional infor- 
mation. 
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Chapter 4. mTropolis Basics 


Chapter 3, “Object-Oriented Design”, outlines 
object-oriented design philosophy. In this 
chapter, mTropolis’ implementation of this 
design philosophy is presented, along with 
other, basic information required to under- 
stand mTropolis. 


OVERVIEW: mTROPOLIS OBJECTS AT 
WORK 

Working with software objects to create so- 
phisticated, dynamic, interactive models of 
real or imaginary environments is theoretical- 
ly very easy. There are only two tasks: 


¢ Create and combine visual and abstract 
software objects. 


* Control the interaction of the objects with 
simple messages. 


mTropolis was created to turn this theory 
into practice. The people at mFactory believe 
that the sophisticated, “live” models at the 
heart of a great multimedia titlke—anything 
from a haunted house to a human body to a 
race-track simulator—can be crafted without 
frustration and tedium. 


mTropolis provides a complete collection of 
components, facilities for creating and alter- 
ing your own, and a way of connecting the ob- 
jects together. This allows the author to focus 
on visually laying out the project and defining 

the messages that will bind together the 
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project’s components, without having to “re- 
invent the wheel” every time a simple opera- 
tion, like loading and running an animation, 
has to occur. 


All of your creative work with mTropolis 
components can be done visually, without in- 
tricate and time-consuming scripting. Com- 
bining components is done via dragging and 
dropping— binding components together in 
a conversation is a point-and-click process. If 
you want a roomful of clocks on a computer 
screen, you can cut and paste the clock com- 
ponent repeatedly with no more difficulty 
than using a word processor. Each of those 
clocks will tell time without any more work 
on your part. Creating your own component 
can be as easy as creating a new circle or 
square in a drawing program. 


A stand-alone title is composed of the same 
objects you work with in the mTropolis au- 
thoring system, along with the instructions 
you gave them on how to interact. The only 
difference between what’s under the hood 
during development, and a stand-alone title, 
is that the stand-alone title doesn’t have dia- 
log boxes or other interfaces that would let 
someone change its fundamental behavior. 


ELEMENTS AND MODIFIERS: 
BUILDING “MEDIA OBJECTS” 

The fundamental building blocks in mTropolis 
are called elements and modifiers. Element 
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components are essentially vessels for media 
and have built-in code for maintaining their 

basic state (e.g., their position). Modifiers are 
programming components that can be added 
to elements to endow them with new capabil- 
ities (e.g., collision detection). The operation 
of both elements’ and modifiers’ code can be 

configured through dialog boxes. 


Combining multiple modifiers with ele- 
ments, configuring their operation, and creat- 
ing conversations between these “modified,” 
author-defined elements is at the heart of the 
authoring process in mTropolis. These au- 
thor-defined elements are still first-class citi- 
zens of mTropolis: they work exactly like 
built-in mTropolis components, and they can 
be freely shared and reused without any 
problems. 


A very important aspect of mTropolis is that 
all of these components are “live.” As men- 

tioned previously, titles can be executed and 
debugged inside the mTropolis development 
environment. To do so, the author switches 
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from the default editing mode in which com- 
ponents are being manipulated and config- 
ured to a runtime mode in which the “live” 
components carry out their tasks at full per- 
formance—the title actually runs inside 
mTropolis. See “Switching to Runtime Mode” 
on page 2.13 of the mTropolis Reference Guide. 


Elements: Creating Media Objects 

When the author creates a new element, it 
does not contain any media. The first step in 
evolving an element towards its final role ina 
title is to link it to external media. This exter- 
nal media can range from simple bitmaps, to 
animations or time-based video/audio. 


Figure 4.1 shows a new graphic element as it 
is first created. Beside it is a graphic element 
that has been linked to a digital video. 


Elements contain snapshots of the external 
media files. For example, in Figure 4.1 the 
first frame of a digital video is shown within 
the boundaries of the element. When the au- 
thor switches from editing mode to runtime 


Figure 4.1 A new graphic element, and a graphic element linked to a QuickTime movie 
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mode, the digital video plays on the screen 
within the element boundaries. 


The author can configure the operation of the 
element through its Element Info dialog box 
(Figure 4.2). This dialog is opened by dou- 
ble-clicking on the element. 


The Element Info dialog options set the me- 
dia’s initial state: hidden or visible, paused or 
unpaused, cached, and so on. 


The element’s configuration does not directly 
alter the external media file. Instead, it alters 
the appearance and behavior of the media at 
runtime, such as its representation on the 
screen, its volume level, etc. 


mTropolis supports three types of elements: 


* Graphic elements, including stills, anima- 
tions, and digital video. 


By [industriat Fiiekat 


¢ Sound elements. 


¢ Text elements. 


Modifiers: Customizing Media Objects 

So far we’ve explained that element compo- 
nents can inherit the capabilities of modifiers. 
In the mTropolis environment, this process is 
simple and direct: an element acquires new 
capabilities or properties when modifiers are 
dragged and dropped on them (Figure 4.3). 


When an element inherits new capabilities or 
properties from modifiers its media is not 
permanently altered. For example, an ele- 
ment containing an image of an orange fish 
can inherit a modifier with a special inking ef- 
fect that causes the fish to appear blue. The 
appearance of the element is changed, but the 
external media remains unaltered. 
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Figure 4.2 The Element Info dialog associated with a video element. 
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Like elements, modifiers can be configured 
through a dialog box. This dialog can be dis- 
played by double-clicking the modifier. Each 
modifier’s dialog is specific to its particular 
capabilities or properties. Figure 4.4 shows 
the dialog for configuring a graphic modifier. 
This dialog controls the particular properties 
that an element would inherit from this mod- 
ifier—in this case, the appearance of its me- 
dia. This dialog also contains the message 
pop-ups used to configure the modifier’s 
messaging operation. These functions are dis- 
cussed in more detail in Chapter 6, “Messag- 
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Figure 4.4 The Graphic Modifier dialog. 
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Figure 4.3 Dragging a modifier from a palette and dropping it on a graphic element. 
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An element combined with one or more 
modifiers can be thought of as a unique au- 
thor-defined mTropolis component linked to 
a specific media file. 


mTropolis comes with a very rich set of mod- 
ifiers that can be combined with elements to 
build titles with sophisticated features. For 
example, one modifier provides vector mo- 
tion control over elements to which it is add- 
ed. Another class of modifiers, called 
variables, endows elements with persistent or 
transient properties, such as the score of a 
game, or the location of a hidden door. Indi- 
vidual modifiers are described in Chapter 12 
of the mTropolis Reference Guide, “Modifier 
Reference”. 


The ability to easily control author-defined 
components is extremely valuable. The au- 
thor no longer needs to think about the state 
of the media as the title evolves. Instead, the 
author works with concrete objects that liter- 
ally “know how to behave.” The tedious work 


of maintaining an object’s state or checking 
on its operation is eliminated. 


Again, we want to emphasize that these au- 
thor-defined components can be freely re- 
used—cut and pasted, duplicated, stored and 
reapplied—across the breadth of a title or 
even in entirely new projects. 


MESSAGING AND USER INTERACTION 
As we have previously explained, messaging 
is the glue that binds object-oriented systems 
together. As a fully fledged object-oriented 
development environment, mTropolis is no 
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different. As you craft your title using mTrop- 
olis components, you bind them together 
with messages. This section provides an over- 
view of how messaging works in the mTrop- 
olis environment. 


The Conversational Model 


The model that best describes the interaction 
in an object-oriented system like mTropolis is 
conversation. In a conversation, the participants 
interact dynamically, changing their respons- 
es according to feedback from others. More 
critically, in object-oriented systems the user 
can be an active participant in the conversation. 
Conversely, the same interaction in a proce- 
dural design requires that all the possible re- 
sponses be predetermined—including those 
of the user. 


The procedural or scripting model is much 
like a cocktail party where every single utter- 
ance is known in advance to every participant. 
Just as this party would be boring for you as 
a participant, new media consumers find ti- 
tles with this predictability to be equally un- 
appealing. Consider the taxi example from 
Chapter 3, “Object-Oriented Design”, a taxi 
simulation in which all routes were predeter- 
mined would quickly bore even a 2-year-old 
child. 


The real world, or any compelling, simulated 
world, is both internally consistent and yet 
unpredictable. The conversational model cre- 
ates consistency because the format of the 
conversation (like choosing a language and 
topic at a party) is determined. The conversa- 
tional model also accommodates unpredict- 
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ability because the content of the 
conversation is not predetermined. Thus, the 
conversational model truly reflects the real 
world: every conversation, from particle 
physics to politics, rests on some form of 
structured exchange between parties—the 
content of which is not known in advance. 


This faithfulness to real-world systems—or 
really, any system that is internally consis- 
tent—means that you can model them more 
naturally and much more quickly. A sword 
fight is both a complex and fluid process with 
an indeterminate outcome. It can also be ele- 
gantly and rapidly modeled by sword and 
fighter components in conversation. Can 
mTropolis produce a sword-fight experience 
that will mesmerize users? We think so. 


Messaging Basics 

The basis of the conversational model, which 
mTropolis employs, is messages. A conversa- 
tion between mTropolis components consists 
of an exchange of messages, which are like 
small, very fast, structured e-mail messages. 
Messages tell a component who is talking to 
it and what that other entity wants done. 


As we have discussed, elements and modifi- 
ers have certain capabilities. These capabili- 
ties can be configured by double-clicking on 
a component’s on-screen representation to 
call up its dialog box. Sending a message to a 
mTropolis component is an alternate, dynam- 
ic vehicle for invoking these capabilities during 
runtime. For example, the graphic modifier 
component in Figure 4.5 invokes its capabil- 


ity when it receives a message called “The 
light is on.” 


Messages are signals, or requests. These signals 
are acted upon by components configured to 
respond to them. Components that receive 
messages, but which are not configured to re- 
spond, merely relay the message to compo- 
nents that they contain. For example, an 
element might contain the graphic modifier 
depicted above. If the element received a 
“The light is off” message, it would pass the 
message to the graphic modifier. Remember, 
as far as the sender of the message is con- 
cerned, the element is a perfectly appropriate 
recipient because it inherits the capabilities of 
the graphic modifier. 


Messages can be generated by the user (like a 
mouse click), by system events (like new data 
becoming available over a network connection), 
and by components themselves (like notifica- 
tion of collision from a collision modifier). 
Regardless of the source of a message, any 
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Figure 4.5 A graphic modifier for switching a 
“light” on and off. 
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component can be configured to respond to 
it. Special modifier components, called mes- 
senger modifiers, can be used to generate ab- 
stract messages (e.g., a “The power is off” 
message) to control the flow of events in a ti- 
tle. 


mTropolis, in general, provides very power- 
ful but uncomplicated facilities for control- 
ling the scope and flow of message 
conversations. For example, a message can be 
sent to every single component in a certain 
portion of a project, or just to a single compo- 
nent. One extremely useful feature of mTrop- 
olis is that authors can define messages using 
any text string for the message name. mTrop- 
olis maintains a dictionary of these author- 
defined messages so that they can be applied 
at any time. 


Benefits of the Messaging System 

One of the major benefits of the mTropolis 
messaging system is that it makes reusability 
a snap. As an author combines elements and 
modifiers into sophisticated author-defined 
components, they are also defining the mes- 
sages that those components use to commu- 
nicate. Consider an author-defined balloon 
element that contains a balloon image, a col- 
lision detection modifier and a motion modi- 
fier. The motion modifier causes the balloon 
element to drift around the screen and the 
collision detection modifier detects any colli- 
sions with sharp objects. 


The motion modifier might be activated upon 
receipt of a message called “There is Wind.” 
The collision detection modifier might report 
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a collision with “’m Popped!” To effectively 
reuse the balloon component in any new title, 
someone unfamiliar with the balloon compo- 
nent would only have to understand these 
messages. 


For example, an author could duplicate the 
balloon component ten times and place the 
copies in a jet fighter title for comic relief. 
When a fighter (itself a sophisticated author- 
defined component) launched, it might gen- 
erate a “There is Wind” message to simulate 


jet-wash. Upon receiving the message, the 
balloons would begin to drift. If any of the 
balloons encountered the sharp radar probe 
on another fighter, the balloon in question 
would generate an “I’m Popped!” message. 
The author could have this message signal a 
sound component to play an explosion, or to 
trigger an animation of the balloon deflating. 


Another important benefit of mTropolis’ mes- 
saging is that user interaction with a title can 
be extremely rich and dynamic. Components 
that not only “know” how to interact with 
each other, but also with the user, can be dy- 
namically introduced under title control or 
user control. Consider a game like SimCity in 
which the user is constantly introducing dif- 
ferent objects, each with its own rich behav- 
iors. In mTropolis, the author would simply 
create components with the desired behav- 
iors. At runtime, the user could introduce as 
many of those components as the game per- 
mitted, and they would dynamically interact 
with each other and with the user without 
any prior scripting or additional program- 
ming. 
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mTropolis’ messaging system also enables 
rapid prototyping and pain-free design 
changes for even the most demanding titles. 
Consider a real-time 3D polygon game with 
fighter bombers. A bridge could have regions 
of “intelligent” polygons that animated differ- 
ently in response to different messages. For 
example, the steel supports of a bridge might 
respond to a “Really Big Bomb” message by 
animating a shattering process. 


The author could add a new weapon with its 
own message, a “Really Hot Bomb.” Without 
disturbing the existing aspects of the bridge’s 
behavior, the author could have the steel sup- 
ports animate themselves melting/twisting in 
response to a “Really Hot Bomb” message. Of 
course, this use of messaging also illuminates 
the incredible realism and detail that mTrop- 
olis makes possible with its intelligent com- 
ponents and messaging system. 


mTropolis’ object-oriented system allows ti- 
tles to be analyzed, designed and implement- 
ed at the same time, saving enormous 
development time. Although a complex, 
event-driven system can be modeled in a pro- 
cedural or command-based authoring tool, 
mTropolis’ messaging system makes the in- 
teractions in the system much easier and fast- 
er to prototype and test. 


STRUCTURE IN mTROPOLIS: A 
HIERARCHY 

As titles become increasingly sophisticated, 
the complexity of their internals also increases. 
mTropolis provides a unique facility for man- 
aging complexity in even the largest, most in- 


volved titles. This facility is the mTropolis 
containment hierarchy, the same hierarchy 
that you can view and rearrange in the 
mTropolis structure view. This section explains 
the containment hierarchy and how it helps 
increase your productivity. 


The mTropolis Containment Hierarchy 
Containers are mTropolis components that 
can literally contain other objects within 
them, just as a paper bag can contain any- 
thing inside it from other paper bags to a 
sandwich. An element is an example of such 
a component, since it can contain modifiers. 
When a container object holds another object 
within it, the container object is called a par- 
ent and the held object is called a child. 


Think of a mother kangaroo containing her 
child within her pouch. If the child compo- 
nent in turn contains another component, the 
child component is considered the parent of 
the object it holds. A container ship can be 
the parent of the containers it holds, which in 
tur are parents to the boxes that they hold, 
which in turn are parents to the Energizer 
Bunnies in the boxes. 


This chain of parents and children is called a 
container hierarchy. We use the word hierarchy 
to mean one branch of a tree, like only the 
maternal branch of parents and children ina 
family tree. In a container hierarchy, just like 
a family tree, it is possible for a parent to have 
more than one child. In mTropolis, children 
of the same parent container are called siblings. 
By the way, one of the best ways to represent 
one branch of a tree is an outline—which is 
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why the structure view is presented as an out- 
line (Figure 4.6). 


Another important aspect of containers is that 
they are endowed with all of the capabilities 
of all of the components in their container hi- 
erarchy. In other words, containment is 
equivalent to inheritance. Consider a truck 
component that contains an engine compo- 
nent that contains an oil reservoir compo- 
nent. The oil reservoir component has the 
capability to be filled. Because the truck com- 
ponent is the ultimate parent in the container 
hierarchy, it can receive a “fill me with oil” 
message on behalf of the oil reservoir compo- 
nent. As far as a component external to the 
truck component’s container hierarchy is 
concerned, the truck component has the ca- 
pability to be filled with oil. 


Now that you understand what a container is, 
you will also understand that a modifier is not 
a container. Modifiers are placed in contain- 
ers, where they do work on behalf of the con- 
tainer—sending messages to and receiving 

messages from other modifiers (generally in- 
side other containers). Whatever capabilities 
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Figure 4.6 A sample Structure View. 
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a container may have are derived from the 
various modifiers placed in its container hier- 
archy. 


If you think back to our author-defined balloon 
component example earlier, the balloon element 
contained various modifiers, such as a mo- 
tion modifier. The capability of the balloon 
component to float around the screen de- 
pended on its containership of the motion 
modifier, which provided that capability. 


Structural containers can be used by the title 
developer to group the various contents of a 
title into organized parts, like the chapters of 
a book or the acts in a play. Some structural 
containers, such as scenes and elements, can 
also contain raw media, such as pictures, 
sounds or animations. 


The mTropolis project itself is a structural 


container that contains section containers, 
subsection containers, scene containers and 
element containers. And, of course, all con- 
tainers can contain modifiers. This hierarchy, 
beginning with the project, is the complete 
container hierarchy of a project that you ac- 
cess through the structure view. 


Behaviors 

A behavior modifier is a special container that 
can hold other modifiers inside it. Behaviors 
can be used to group collections of modifiers 
that work in close concert into “supermodifi- 
ers” that provide more sophisticated opera- 
tions than single modifiers—hence the term 
behavior. Behaviors, like other modifiers, in- 
terpret messages. The primary use of messag- 
ing a behavior is to collectively enable or 
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disable the group of modifiers contained 
within it. 

This feature of behaviors is intended to help 
authors manage complexity by gathering to- 
gether cooperating modifiers under one roof. 
Powerful behaviors can be dragged and 
dropped as needed, either from libraries or 
from different sections of a project. In gener- 
al, behaviors promote clean reuse of logic and 


enable programmers to deliver sophisticated 
title operations to artists in drag-and-droppable 
packages. 


Another special feature of a behavior is that it 
can contain another behavior within it, and 

that child behavior can be parent to another 
behavior in turn, to an arbitrary depth. This 
feature permits the creation of an extremely 

sophisticated behavior at the top of a container 
hierarchy of behaviors. 


Consider the behavior of a variety of pests: 
they avoid light. But cockroaches also run 
from light only under certain conditions. A 
light avoidance behavior could be contained 
within a cockroach behavior, selectively 
switched on under certain conditions, to 
quickly, simply and easily model a cock- 
roach. 


It is important to remember that this behavior 
containment hierarchy is a part of the project 
containment hierarchy that can be inspected 
and altered through the structure view. Part 

of the power of the project containment hier- 
archy is that is contiguous and all-embracing. 


Messaging and the Containment Hierarchy 
The containment hierarchy fulfills an impor- 
tant function besides providing a framework 
to organize the inclusion of components 
within one another. Each successively higher 
level of the container hierarchy represents a 
higher level of abstraction in the project, an 
arrangement that actually helps you direct 
the flow of messages quickly and easily, even 
in complex projects. 


Consider a project for a children’s edutainment 
title on physics. Because gravity and friction 
are constant presences in the physical world, 
you might place modifiers for those charac- 
teristics at the project level. Thus, the project 
would contain two modifiers and, as well, 
perhaps sections representing different ex- 
periments or rooms in a virtual physics lab. 


Any good tutorial should show what happens 
when constants are changed. If the child 
clicks an “antigravity” switch in a room of the 
title, gravity should switch off. Of course, ina 
language like C++, you would have to senda 
message directly to the gravity modifier. That 
also implies that you remember exactly where 
the modifier is. In mTropolis, you have much 
more flexibility in messaging, thanks to the 
containment hierarchy. 


First, the containment hierarchy enables mes- 
sage “broadcasting.” You could simply search 
the message list for “gravity,” locating the 
“Turn off Gravity” message. Then you could 
literally target the project, and mTropolis would 
“cascade” the message from the project level 
on down through the entire containment hi- 
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erarchy. Any component, contained anywhere 
in the hierarchy, capable of responding to the 
“Turn off Gravity” message would do its stuff. 
In this case, only the gravity modifier con- 
tained by the project would act on the mes- 
sage. 


The advantage of broadcasting is that you can 
cause global changes without laboriously 
specifying each and every component that 
needs to act on a message. In the example 
above, if gravity modifiers were scattered 
throughout the containment hierarchy, they 
would turn themselves off without any fur- 
ther work on your part. On the other hand, 
you may not want to cause entirely global 
changes. Fortunately, the containment hier- 
archy enables more precise targeting of mes- 
sages. 


Broadcasting is simply the most general case 
of what is called “message targeting” in 
mTropolis. You can also “target” a message at 
any level of the containment hierarchy froma 
single, indivisible modifier at the very bottom 
to some constrained portion of the contain- 
ment hierarchy. In the preceding example, 
you could target the “Turn off Gravity” message 
to only a section of the project. The message 
would cascade only through the section, 
down to scenes representing particular 
rooms, onto the elements and modifiers in 
those scenes, and nowhere else in the project 
as shown in Figure 4.7. 


Basic Rules of the mTropolis Containment Hier- 
archy 
Remember the following basic “rules” of the 


mTropolis containment hierarchy: 
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Containment is equivalent to inheritance; 
as far as any entity outside of a container is 
concerned, the container has all of the ca- 
pabilities of whatever it contains. 


All mTropolis components are a container 
except modifiers. 


All containers can contain modifiers and 
behaviors. 


All containers can contain other containers; 
however, 


Only elements and behaviors can contain 
other containers like themselves. 


All mTropolis objects can be the target ofa 
message, but a modifier (or the system/us- 
er) must be the originator of the message 

and another modifier will actually process 
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Figure 4.7 Message passing between components. 
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the message and do the work. The only ex- 
ception is that elements can directly receive 
command messages to change their basic 
appearance. For example, an element con- 
taining a QuickTime movie can be directly 
commanded to play the movie. 
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Chapter 5. mTropolis Components 


This chapter discusses mTropolis compo- 
nents, how they work and their role in the 
mTropolis containment hierarchy. 


THE ELEMENT COMPONENT: 
PUTTING IT IN CONTEXT 

The fundamental building block of a title is 
an element. An element can be linked to an 
external media file, to display still images or 
play time-based media. Elements have built- 
in code for maintaining their basic state (e.g., 
the element’s position) and controlling the 
appearance of media they contain. This sec- 
tion discusses elements just enough to help 
place the other mTropolis components in con- 
text. We'll discuss elements in more depth lat- 
er in this chapter. 


Elements and External Media 

The author creates elements and links media 
to them. The appearance of an element 
changes to indicate the media to which it is 
linked. For example, ifan element is linked to 
a QuickTime movie, a thumbnail from the 
first frame of the QuickTime movie is shown 
within the element’s boundaries. Elements 
can be resized and positioned in the layout 
view. 


There are three basic types of media elements 
in the mTropolis environment: 
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Graphic Elements 

Graphic elements can be linked to images (e.g., 
PICTs), digital video (e.g., QuickTime mov- 
ies), and animations (in mTropolis’ propri- 
etary animation format, called “mToons”). 
Figure 5.1 shows three graphic elements 
linked to different types of media. 


Sound Elements 
Sound elements can be linked to sound files 
(e.g., AIFF, AIFC, and snd files). 


Text Elements 

Text elements cannot be linked to external 
text files. However, text can be entered into 
text elements and formatted within mTropo- 
lis. 


Figure 5.1 Graphic elements linked to a PICT, Quick- 
Time movie, and mToon. 
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ELEMENTS AND THE CONTAINMENT 
HIERARCHY 

Elements are always contained by other com- 
ponents, either other elements or scene com- 
ponents. When a new project is opened, 
mTropolis provides a project component 
(named “Untitled-1”), a section component 
(named “Untitled Section”), a subsection 
component (named “Untitled Subsection”), a 
shared scene component (named “Untitled 
Shared Scene”), and a scene component 
(named “Untitled Scene”). These components 
are described in more detail below. Figure 
5.2 shows a structural view of a new mTrop- 
olis project. 


Project Components 

A project component is a structural container 
that holds an entire title within it. The children 
of a project are sections. A project can only 
contain sections and modifiers. The project’s 
ability to contain modifiers is useful for creat- 
ing modifiers that modify the actions of the 
entire title. Projects cannot contain other 
projects. 
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Figure 5.2 Structure view of a new mTropolis 
project. 


Section Components 

A section component is a structural container 
that can be used by the title developer to 
gather different chunks of a title into groups 
that logically belong together. For example, a 
title developer for a travel game might put ev- 
erything to do with Africa under a single sec- 
tion. A section is most closely analogous to an 
act in a play or a chapter within a book. Sec- 
tions are parents to subsections. A section can 
only contain subsections and modifiers. Sec- 
tions cannot contain other sections. 


Subsection Components 

A subsection component is a structural con- 
tainer that can be used by the title developer 
to divide the content of a section more finely, 
literally like a subsection in a book. For ex- 
ample, the title developer for a travel game 
might put everything to do with the country 
of Kenya in a subsection, the parent of which 
would be the Africa section. Subsections are 
parents to shared scenes and scenes. Subsec- 
tions can only contain a single shared scene, 
multiple scenes, and modifiers. Subsections 
cannot contain other subsections. 


Shared Scene Components 

The shared scene component is a structural 
container that is a peer of scene containers. It 
is used to contain elements common to all 
scenes in a subsection. A music or voice 
track, for example, might be placed in the 
shared scene. Background images common 
across scenes in a subsection can also be 
placed in the shared scene. In our African 
travel project, a shared scene would maintain 
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the appearance of the plains across different 
Kenyan scenes, as well as providing common 
background music. 


Shared scenes can only contain elements and 
modifiers. Shared scenes cannot contain 
scenes or other shared scenes. Also, only one 
shared scene is ever present in a subsection. 
Shared scenes can also have graphical media 
assets linked directly to them. 


In terms of layer order (as you can inspect 
with the layer view), shared scenes are drawn 
by default behind the scenes that are their 
siblings. This convention stems from the fact 
that shared scenes are intended to provide 
common backgrounds for scenes. 


Scene Components 

A scene component is a structural container 
that is very much like the scene ina play. As 
ascene ina play contains all the props and ac- 
tors required to convey some discrete piece of 
interactivity to an audience, a scene ina 
mTropolis title contains all the components 
to do the same for a user. A scene presents a 
microcosm—like an African watering hole or 
a room in a haunted house—that contains 
child components for all of the props and ac- 
tors in that microcosm. 


Scenes can only contain elements and modi- 
fiers. Scenes cannot contain other scenes. 
Note, however, that there is no limit to the 
number of scenes that can be present ina 
subsection. Like shared scenes, scenes can 
have graphical media assets linked directly to 
them. 
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Element Components 

An element component is a structural con- 
tainer that is the workhorse of mTropolis. El- 
ements can be linked to raw media such as 
pictures, sounds and animations. 


Elements can also contain modifiers, which 
help to bring the raw media they contain to 
life. Consider a scene representing an African 
plain. The title author would use elements 
containing pictures of dry grass and trees to 
create a compelling image of the plain. Now 
consider that the author wants a vulture to fly 
around the plain. 


An element simply containing a picture of a 
vulture, or even containing various frames to 
animate the vulture’s wings, will not accom- 
plish the objective of making the vulture fly. 
The vulture element needs to contain a motion 
modifier component. Once the author drops 
on that component, the vulture element would 
be endowed with the motion capabilities of 
that motion modifier. The vulture could be 
set to follow a preprogrammed path, or to 
move about randomly as it iterated through 
its wing animation. Now consider that the 
tree elements of the plain could contain colli- 
sion detection modifiers. The tree elements 
would then have the ability to detect a colli- 
sion with the vulture element. 


Elements can also be the parents of other ele- 
ments. Why would an element contain an- 
other element? Consider the vulture 
described above. The wings of the vulture 
might have been created separately from the 
vulture’s body, so the author might receive 
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the vulture as three separate elements created 
by the art department. The vulture’s body 
needs to carry the wings along the same path 
that it travels. The simple solution is to attach 
the wings to the body by containing the two 
wing elements inside the body element. The 
final, collective vulture element will move 
along the same path. 


HOW GRAPHIC COMPONENTS ARE 
DRAWN 


Only shared scenes, scenes and elements are 
actually drawn on the screen by mTropolis. 
This section contains some basic information 
on how these components are drawn. 


Elements contained by a scene draw by default 
on top of the scene and are contained within 
its boundaries. Scenes are drawn by default on 
top of the shared scene that services them. 


Elements are automatically assigned a layer 
order when they are added to a scene. The 
layer order of new elements increments as they 
are added to the scene. Each layer contains only 
asingle element. The layer order can be changed 
dynamically under program control. Note that 
layer order is independent of the parent/child re- 
lationships of elements in a scene. Layer orders 
are described in more detail in Chapter 10 of the 
mTropolis Reference Guide, “Layers Window”. 


By default, mTropolis builds the scene off- 
screen in memory before it is presented to the 
viewer. The viewer does not see each element 
added to the scene, but rather views the result 
of layering one element on top of another. 


In this so-called “2.5D” approach, elements 
always appear above elements with a lower 
draw order and below elements with a higher 
draw order when they are redrawn. Because 
they are properly clipped, this approach cre- 
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Figure 5.3 The “2.5 D” effect of layer order. 
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ates the illusion of a 3D perspective. Figure 
5.3 illustrates how layer ordering affects 
graphic elements. 


mTropolis provides the option of displaying 
elements “direct to screen”, turning an ele- 
ment’s draw order off. This feature is useful 
when you want an element to be always 
drawn on top of everything else on screen. 


MODIFIERS 


Modifiers are special mTropolis components 
that modify the properties of other components 
in a project. Some modifiers are built into 
mTropolis, but new ones can be plugged in 
so seamlessly that they are indistinguishable 
from the built-in modifiers. 


Modifiers are used by dragging them from one of 
the modifier palettes and dropping them on the 
object that they are to modify. Each modifier on 
the modifier palettes has unique capabilities 
or properties. When a modifier is dropped 
onto a component, the component assumes 
these capabilities or properties. 


For example, a gradient modifier has the abil- 
ity to alter the visual characteristics of graphic 
elements. When dropped onto a graphic ele- 
ment, the gradient modifier’s capabilities are 
added to the information that makes up that 
object, as shown in Figure 5.4. 


While some modifiers have the ability to 
change the visible characteristics of the ele- 
ments onto which they are placed, other 
modifiers change invisible characteristics, or 
properties, of the element that contains them. 
For example, when a point variable modifier 
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that contains the value 2.5 is placed on an el- 
ement, the physical representation of the ele- 
ment does not change, but its content, the 
value 2.5, becomes an intrinsic part of the el- 
ement that contains it. 


All modifiers can be configured (i.e., their ca- 
pabilities can be customized) by changing the 
default settings in their modifier dialogs. In 
addition, most modifiers can be configured to 
apply their effects at specific times through a 
process called messaging. 


A message in mTropolis can be as simple as a 
mouse click, or as complex as an author-de- 
fined message that is generated only after spe- 
cific conditions in the runtime environment 
have been met. Some messages are generated 
by mTropolis during runtime and automati- 
cally sent to specific components throughout 
the project, and others can be sent to compo- 
nents from special modifiers called messen- 
gers. 


Complete information on mTropolis modifi- 
ers can be found in Chapter 12 of the mTrop- 
olis Reference Guide, “Modifier Reference”. 
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Figure 5.4 The gradient modifier, placed on a 
graphic element 
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Behavior Modifiers 

A special type of modifier is worth mention- 
ing here. A behavior is a special component in 
the mTropolis environment. It can be used to 
encapsulate (i.e., contain) groups of modifi- 
ers and other behaviors. 


Behaviors can be used to hierarchically group 
collections of modifiers that work in close 
concert. Each collection can be enabled or 
disabled with messages, creating “super mod- 
ifiers” that provide more complex operations 
than single modifiers alone. 


The power of behaviors lies in the fact that 
they can be made switchable. That is, they 
can be turned on or off with messages. When 
a behavior is switched off, all of the modifiers 
it encloses are disabled. When a behavior is 
switched on, individual behaviors or modifiers 
within a behavior can then be activated by in- 


coming messages. This feature allows the au- 
thor to create and control components with 
very sophisticated behaviors and capabilities. 


A comlete description of the behavior modifi- 


er can be found in “Behavior” on page 12.13 
of the mTropolis Reference Guide. 


Aliases 

One powerful mTropolis feature is the ability 
to make a special copy of any modifier (in- 
cluding behavior modifiers), called an alias. 
Creating an alias makes a “master copy” of a 
modifier and places it on mTropolis’ Alias 
Palette. Modifiers on the alias palette can be 
dragged and dropped onto any element in a 
project. All modifiers placed in this way share 


the same settings and all aliases of a modifier 
can be updated by editing any instance of that 
modifier. 


This feature is useful in complex projects 
where a modifier may be employed in an 
identical fashion in many different sections of 
the project. For example, in an adventure 
game, a graphic modifier might apply the 
same effect to images that represent stone 
walls throughout the game. During the au- 
thoring process, changing the settings of 
many identical modifiers can be time con- 
suming. Similarly, sending many messages 
during runtime to identical modifiers could 
also be time consuming. 


Using aliases of the graphic modifier in our 
example would permit the author to make a 
change to either the original or any of its 
aliases, and that change would instantly oc- 
cur in all copies of the modifier. 


Aliases can be very powerful when used with 
behavior modifiers. Dropping a new modifier 
into an aliased behavior causes all instances 
of that behavior to be updated. 


For complete information on creating and 
managing aliases, see “Alias Palette” on 
page 11.7 of the mTropolis Reference Guide. 
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Chapter 6. Messaging 


Chapter 5, “mTropolis Components” out- 
lined the role that components play in the 
mTropolis authoring environment. This 
chapter focuses on the messaging relation- 
ships between components. 


ACTIVATING ELEMENTS AND 
MODIFIERS 

As we discussed previously, messages are 
sent and received by modifiers at various lev- 
els of the project container hierarchy. Modifi- 
ers can also receive messages from the 
mTropolis runtime environment itself, such 
as network events or user mouse events. Ele- 
ments do not send messages, but they can re- 
ceive certain special messages directly from 
modifiers. Behaviors, while they do not send 
messages either, can be switched on or off by 
messages. 


Messages are essentially signals that tell ele- 
ments and modifiers to engage in some oper- 
ation. Consider the graphic modifier depicted 
in Figure 6.1, placed on some arbitrary ele- 
ment. 


In this example, the graphic modifier listens 
for a Mouse Down message. When that mes- 
sage is sent to it, it turns the element blue. 
When it receives the Mouse Up message, it 
returns the element to its default color 
(black). 


Activating Elements and Modifiers 


An important point about messages is that 
they are always available to the author, re- 
gardless of whether they are associated with 
some specific environmental event. In the ex- 
ample above, the Mouse Down message 
could have been sent to the graphic modifier 
from the mTropolis environment in response 
to a user mouse-click. However, it could also 
have been sent by a messenger modifier con- 
figured to send a Mouse Down message in re- 
sponse to some condition. The ability to 
simulate external events under program con- 
trol is particularly useful for debugging and 
testing. 


MESSENGER MODIFIERS: BUILDING 
LOGIC 

Messenger modifiers (often referred to simply 
as “messengers”) are dedicated to sending 
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Figure 6.1 Graphic modifier dialog configured to 
activate on Mouse Down and deactivate on 
Mouse Up messages. 
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and receiving messages. Messengers are the 
glue that implements the abstract logic of a 
mTropolis title. For example, a timer messen- 
ger listens for a message and delays for a se- 
lected period of time. Then it sends another 
message out. 


The timer messenger dialog shown below 
(Figure 6.2) illustrates the full power of mes- 
saging in mTropolis. Through their dialogs, 
messengers can be configured to send specific 
messages, to specific destinations with any 
data that the author wants to send and re- 
ceive. Messaging is a powerful, but simple 
process. The four “W’s” of messaging—when, 
what, where, and with—are described below. 


Timer Messenc 


ga Timer Messenger 


When 
The timer messenger, like most modifiers, 


has two “When” pop-up menus. When the 
modifier receives the message selected by the 
“Execute When” pop-up, the modifier will 
activate as it has been configured to do so. 
When the modifier receives the message se- 
lected by the “Terminate When” pop-up, it 
will return to an inactive state. 


What 

The “Message/Command” pop-up is used to 
select the specific message to be sent when 
the messenger is activated. 


Where 
The “Destination” pop-up is used to select 


where the selected message will be sent. 
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Message “Command: | 
None 


Destination: 


“When" 
Execute When: Terminate when: 
Mouse Up ha None hal 
“What" 
With: ; 
[x] Jone ~| With 
“Where” 


a 


Message Options 
io Immediate ea Cascade 


ea) Relay 


Figure 6.2 A typical messenger dialog. 
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With 

Optionally, data can be sent with a message. 
The “With” pop-up is used to select a variable 
or constant value to send. 


Each of the pop-ups will be described in turn. 


“When” and “What” Message Pop-Ups 
The ‘When’ and ‘What’ pop-ups deal with the 
same entity—messages—so we'll describe 
them together. 


Together the “When” pop-ups control the 
conditions under which the messenger (or 
any modifier, for that matter) will operate. 
The first “When” pop-up selects the message 
that will activate the messenger. It can be any 
arbitrary message, either author-defined or 
predefined, just as with any other modifier. 
The second ‘When’ pop-up selects the mes- 
sage that will return the messenger to an in- 
active state, just as with any other modifier. 


The “What” pop-up is distinct from the 
“When” pop-ups in that it determines the out- 
put of the messenger. The message selected by 
the “What” pop-up will be sent when the 
messenger activates. This message can be any 
message available in the mTropolis environ- 
ment, either author-defined or predefined. 
And, as mentioned above, this message could 
be a simulated environment message, such as 
a Mouse Down. 


See “The ‘When’ Pop-Up Menu’ on page 13.1 
of the mTropolis Reference Guide and “The 
Message/Command Pop-Up Menu” on 

page 13.2 of the mTropolis Reference Guide for 
complete information on these menus. 
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“Where” Destination Pop-Up 

The “Where” pop-up selects the destination, 
or target, of a messenger’s output message. 
The ultimate target must be another modifier, 
an element or a behavior; however, these 
components can be anywhere within a 
project’s containment hierarchy. In the case 
of a modifier or behavior, they could be nest- 
ed within a behavior as well. 


Container Hierarchy and Messages 

As explained above, the destination for a mes- 
senger’s output message can be either a spe- 
cific component, or an arbitrary level of a 
project, or a behavior containment hierarchy. 
mTropolis will automatically handle cascad- 
ing the message down through the contain- 
ment hierarchy to the elements, modifiers or 
behaviors that might be listening for the mes- 
sage that was sent. Remember, we explained 
the power of the containment hierarchy for 
controlling the flow of messages “Messaging and 
the Containment Hierarchy” on page 4.10. 


Some examples of possible message destina- 
tions in the container hierarchy: 


¢ The element that contains the messenger 
modifier (i.e., to its immediate parent in 
the containment hierarchy): 


Element 


Messenger 
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¢ Another modifier contained by the same el- 
ement (i.e., to its sibling in the contain- 
ment hierarchy): 


Element 


Messenger 


Cursor Modifier 


* To another element (i-e., to a sibling of its 
parent in the containment hierarchy): 


{fm Sibling Element 


| Element 


Messenger 


The illustration below depicts a messenger 
sending a message to an arbitrary level in the 
containment hierarchy and how that message 
cascades down to the eventual recipients: 


re Section 
4 La Subsection 


HT] Element 3 


In the preceding illustration, the section is the 
container (and parent) to the subsection, 


which is in turn the container and parent to 

the scene, in turn the container and parent to 
elements 1, 2 and 3. A messenger contained 
by element 3 could target its message at the 

section. That message would cascade down to 
every component in the section’s portion of 

the containment hierarchy. 


There are two points to make about this use 
of the containment hierarchy for messaging. 
First, the message sent by the messenger goes 
directly to the section and does not travel up 
the containment hierarchy. Second, the mes- 
sage, as it cascades down the containment hier- 
archy, is only acted upon by modifiers that 
have specified in their “When” menus that 
they wish to be activated by the message in 
question. All other components ignore the 
message. 


A very powerful feature of messaging in con- 
junction with the containment hierarchy is 
relative message targeting. You have seen that 
you can specify some abstract level of the 
containment hierarchy as a target, and that 
mTropolis will handle all of the details of cas- 
cading the message to the possible recipients. 


Relative message targeting enables you to tar- 
get other components by their relation to a 
modifier, rather than their specific names or 
positions in the containment hierarchy. For 
example, you could specify that you want a 
message sent to a modifier’s parent in the 
containment hierarchy, or its parent’s parent, 
all the way up the hierarchy. Or, you could 
send a message to its parent’s sibling. 
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Behavior Containment Hierarchy and Messages 
As we mentioned in our discussion of behav- 
iors in “Behavior Modifiers” on page 5.6, be- 
haviors can contain modifiers, as well as be 
nested inside of other behaviors. This behav- 
ior containment hierarchy is a part of the 
project containment hierarchy, inspectable 
and alterable through the structure view. The 
following illustration shows the relationships 
between behaviors, modifiers and an element. 


[esi Element 


+ ris Messenger 


: Behawior 1 


Messenger 


Behavior 2 


Messenger 


Behavior | is contained by the element. Behav- 
ior 2 is contained by Behavior 1. Behavior 2 can 
target the modifiers contained by Behavior 1. 
In order for the modifier contained by Behav- 
ior 2 to send a message to the modifier on the 
element, it must target the element. 
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The next illustration shows the way a mes- 
sage is broadcast to an element that contains 
both a behavior and another element. 


Messenger 


: Behavior 1 
@ Messenger 


Messenger 


ri Messenger 
{el Element 2 


Element 2 is contained by Element 1. A mes- 
sage broadcast to Element | cascades succes- 
sively down the containment hierarchy. 


Behavior Dialog 

Figure 6.3 shows a behavior on an element, 
with the editing dialog for the behavior open 
to show the modifiers it contains. 


Notice that the behavior dialog box shows the 
order of modifiers (1, 2, 3) and the particular 
messages that activate them (Mouse Up, 
Switch On, and Parent Enabled). mTropolis 
processes messages in the order that they are 
received, and looks for the first modifier that 
will respond to the message currently being 
processed. 


In Figure 6.3, a Light Switch behavior pro- 
vides a concrete demonstration of how be- 
haviors can cleanly group cooperating 
modifiers into a high-level behavioral compo- 
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nent. The behavior in this example contains 
the modifiers that would be activated when 
the user clicked on a light switch element. 
However, once created, the light switch be- 
havior can be dragged onto other switch ele- 
ments throughout a project. Behaviors truly 
promote easy and painless reusability. 


We have previously mentioned that behav- 
iors, like modifiers, can be activated and deacti- 
vated through the receipt of messages. When 
checked, the Switchable check-box in the be- 
havior dialog box (Figure 6.3) enables a be- 
havior to be controlled in this fashion. The 
left “When” pop-up specifies the message that 
will enable the behavior and the right “When” 
pop-up specifies the message that will disable 
the behavior. 


If a behavior is deactivated, all components 
within its chunk of the containment hierar- 


chy are effectively “deaf,” not listening to any 
messages. 


This “switchability” of behaviors is especially 
powerful when behaviors are nested within 
each other. As we discussed previously, be- 
haviors can be nested so that they fire activa- 
tion and deactivation messages downwards 
in a sophisticated cascade, almost like a neu- 
ral network. This “gating” of nested behaviors 
can be used to model very complex logic in a 
manageable and reusable manner. 


See “The Destination Pop-Up Menu” on 
page 13.21 of the mTropolis Reference Guide 
for complete information on the destination 
menu. 


“With” Menu: Sending Data 
The “With” message pop-up allows a messen- 
ger to pass data along with the message out- 


Untitled-1 : Light Switch Behavior 


8 [Light Switch Behavior Ei switchable 


Enable when: 


[Power is On | Power is Off ial 


Disable when: 


Mouse Up 
Switch On 
Parent Enabled 


Fa) 


Messenger 


as 


Sound Effect Modifier Graphic Modifier 


Figure 6.3 A behavior modifier dialog. 
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put by a messenger. For example, 
information about the current element’s 
screen position, where the user clicked on the 
screen, or current values of variables could be 
sent along with the message. 


A messenger can send no data (the default se- 
lection); it can send a constant value (entered 
in a dialog box while configuring the messen- 
ger’s operation); it can relay the value that it, 
the messenger, received from the message 
that activated it (the “incoming data”), and it 
can also send the contents of any variable 
modifier accessible to it. 


See “The “With” Pop-Up Menu” on 
page 13.20 of the mTropolis Reference Guide 
for complete information on this menu. 


TYPES OF MESSAGES 


Messages in mTropolis can be divided into 
two types. The first type, which includes all 
author-defined messages and the majority of 
all built-in mTropolis messages, act as signals 
or conveyors of information. For example, 
the Mouse Down message signals the recipi- 
ent that someone clicked the mouse. These 
signal messages can be subdivided into two 
types, “environment messages” and “author 
messages”. 


The second major type of message is an im- 
perative, or command. Sending a command 
message constitutes a demand that the recipient 
perform some action, and it cannot be ig- 
nored. Command messages (called commands) 
are primarily used to control the behavior of 


elements; while modifiers can send commands, 
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the command messages have no specific 
meaning to them. For example, the Play com- 
mand would immediately cause a modifier’s 
element to play any time-sensitive media that 
it contained; however, the play command is 
simply another message to which the modifi- 
er can be configured to respond. 


This section explains the various types of 
messages available for use in mTropolis. 
More information on these messages can be 
found in “Environment Messages” on 

page 13.2 of the mTropolis Reference Guide, 
“Author Messages” on page 13.4 of the 
mTropolis Reference Guide, and “Commands” 
on page 13.4 of the mTropolis Reference Guide. 


Commands: Control Signals 

Commands appear in the “What” menus as 
italicized text to distinguish them from other 
messages. Figure 6.4 shows one of the cas- 
cading menus available from the Message/ 
Command pop-up menu. 


Commands are different from signals in the 
following two respects: 


* Commands act directly on elements. Ele- 
ments do not have to be configured to 
“hear” commands, and they respond to 


them immediately without interpretation. 
For example, there are commands that can 
be sent to a digital video to play or hide, or 
to a still image to show or hide. 


Since commands act directly on elements, 
they do not affect modifiers. The author 
cannot, for example, command a modifier 
to Play or Pause. However, modifiers can 
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receive and interpret commands, or pass 
them on to elements if directed to do so. 


* Commands are like any other message in 
that they can be targeted to a specific ele- 
ment, toa specific level of the containment hi- 
erarchy, or to relatively positioned 
elements. While the command acts on the 
recipient element immediately, its result is 
passed on to modifiers within that element 
as a signal message. For example, if the 
command Pause is sent to an element, the 
modifiers within it could listen to and act 
on the resulting signal, which would be 
“Paused.” 


Here are some examples of commands: 


* Play: Play the animation or digital video 
from the first cel in its range. 


Execute When: 
Message Specifi 
Message Command: 


Scroll Up 


Destination: 


Element 


Messenger 


Author Messages} 
> 


Play Control 


* Stop: Stop the animation or digital video 
and hide it. 


* Close Project: Quit the title. 


Chapter 13 of the mTropolis Reference Guide, 
“Modifier Pop-Up Menus and Message Refer- 
ence” for a complete list of commands. 


Author Messages and Environment 
Messages 

While command messages are imperatives 
that elements cannot ignore, signal messages 
inform modifiers that an event has occurred. 
If the modifier is listening for that information, it 
acts upon it. 


Signal messages fall into two types: author 
messages and environment messages. 


Show 
Hide 


Transition 


; Message Options 


EX) Immediate Parent 
Scene 


Project 


Shared Scene 


Select 
Deselect 
Toggle Select 


Edit Llement 
Edit Done 
Uodate Caloulated Fields 


Get Attribute 
Set Attribute 


Sorell Bown 
Sorell Left 
Sorell Right 


Preload Medis 


Figure 6.4 Commands in the Message/Command menu’s “Element” section. 
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Author Messages 
Author messages are defined by the author by 


entering the text of a new author message in 
the “When” pop-up of a modifier. mTropolis 
will ask the author if he wishes to create a 
new author message. 


Author messages are never sent by the sys- 
tem, they are only sent by messenger modifi- 
ers, under the author’s control. However, any 
modifier, through its “When” pop-ups, can 
be controlled by any author messages. 


Environment Messages 
Environment messages appear as options on 


the message menus. Examples include: 


* Mouse Down: the mouse button was 
pressed while the cursor was over an ele- 
ment. 


¢ At First Cel: the first cel in an animation 
contained by an element has been reached. 


¢ Motion Started: an element has started 
moving. 


¢ Scene Ended: the scene has ended. 


While mTropolis itself sends environment 
messages to modifiers that are listening for 
them, mTropolis does not have a monopoly 
on the use of environment messages. As we 
mentioned previously in this chapter, the au- 
thor can send environment messages from a 
messenger at will. For example, an author 
wishing to test some user interaction logic 
could emulate a mouse event by simply send- 
ing a Mouse Down message from a particular 
messenger. 
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Chapter 7. Tutorial 


This tutorial provides a general introduction 
to mTropolis. It is intended for new users 
who want to get a feel for what mTropolis can 
do and how to use the mTropolis authoring 
environment. In this tutorial, you'll create a 
multimedia “puzzle”. The process of author- 
ing in mTropolis is demonstrated 
step-by-step, beginning with adding media to 
the first scene. 


WHAT YOU'LL NEED 

¢ mTropolis must be installed on your ma- 
chine. Installation instructions can be 
found in the “Read Me First!” file on the 
mTropolis CD-ROM. 


* The tutorial files are installed by default 
when mTropolis is installed. Tutorial files 
can be found in the “mTutorial” folder of 

the mTropolis installation. If the tutorial 

has not been installed, it can be installed by 
running the installer from the mTropolis 

CD-ROM, or by dragging the “mTutorial” 

folder from the CD to your hard disk. 


¢ For best performance, make sure your 


monitor is set to display 256 colors. 


Tutorial Project Description 
Let’s begin by looking at the completed puz- 
zle project. 


* Open the completed tutorial project into 
mTropolis by dragging the Completed Tu- 


What You'll Need 


torial icon, found in the mTutorial folder, 
onto the mTropolis icon. If you have mul- 
tiple versions of mTropolis installed (e.g., 
both the 68K and PPC versions), be sure to 
select the correct one for your machine. 


* Ifa dialog appears prompting to search for 
the media files, click on the Search button. 
A folder selection dialog appears. Use it to 
select the “mTutorial” folder on your drive. 
mTropolis will find the media files it needs 
in the subdirectories of this folder. The 
mTropolis interface appears with the com- 
pleted tutorial project shown in its layout 
view. 


¢ The project is shown in edit mode, where 
changes could be made to the project. To 
view the project as a user would see it, 
press 36-T to switch to runtime mode. The 
project will run from its first scene. 


The first scene of the project shows a Quick- 
Time movie of mFactory’s “M” logo being 
drawn on a napkin. When the movie is fin- 
ished playing, a new scene appears. 


The second scene (Figure 7.1) shows pieces 
of a puzzle spread randomly about the 
screen. The pieces can be dragged around the 
screen. If a piece is dropped near its correct 
position on the backdrop, it “snaps” into 
place with an audible “clang”. The pieces 
form a machine that looks like the mFactory 
logo. When all the pieces are in their proper 
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Figure 7.1 Solving the mTutorial puzzle 


places, the “M” machine springs to life as a se- 
ries of animations on different parts of the 
“M” begin to play. 


When finished with the puzzle, click on the 
“manhole” icon in the lower right corner of 
the screen to jump to a credits scene. When 
the credits have finished, the project ends 
and mTropolis returns to edit mode. 


START A NEW PROJECT 

When you are finished exploring the com- 
pleted puzzle, close the finished tutorial 
project by selecting Close from the mTropolis 
File menu. If you are prompted to save any 


changes, click the Don’t Save button. The tu- 
torial’s layout window will disappear. 


Now we'll recreate the puzzle project. Start a 
new project by selecting New-Project from 
the File menu. A new, empty project appears. 
This project contains an empty section, sub- 
section, and scene. The empty scene is dis- 
played in the layout view. 


CREATE THE FIRST SCENE 
In the first part of this tutorial, we'll begin by 
adding media to the scene. 


Start a New Project 
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Adding the Media 
Let’s add the background image for the logo 
movie that plays when the project is first run. 


¢ Click on the Scene to select it. 


* Choose Link Media-File from the File 
menu. A standard file selection dialog ap- 
pears. 


¢ Choose the image named Napkin.pict 
from the PICTs folder, found inside the 
mTutorial Media folder. The Napkin.pict 
image fills the scene. 


Now let’s put the logo QuickTime movie on 
top of this background image. First we'll cre- 
ate an element to contain the QuickTime 
movie. 


* Select the graphic el- 
ement tool (the 
box-shaped tool) in 
the tool palette. 


¢ Drag anywhere on 


the scene to create an 
empty graphic element of any size. 


¢ Select the new element and choose Link 
Media-File from the File menu. A standard 
file selection dialog appears. 


¢ Choose the file named mSketch.MooV in 
the MOOVs folder, found inside the mTu- 
torial Media folder. 


If the Application Preferences (accessed 
through the Edit menu) are set to their de- 
faults, the element will resize automatically to 
the size of the QuickTime movie. However, if 
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it doesn’t resize automatically, select the ele- 
ment and select Revert Size from the Object 
menu. 


Position the Movie 

Let’s position the QuickTime element 
(mSketch.MooV) precisely using the Object 
Info palette. 


* If the Object Info palette (shown below) is 
not already visible, select Object Info Pal- 
ette from the View menu. The Object Info 
palette appears. This palette shows sizing 
and position information for the currently 
selected object. 


¢ Select the mSketch.MooV element, and enter 
167 in the “X” field and 64 in the “Y” field. 
Use the tab key to jump between fields and 


the enter key to confirm the final data en- 
try. 
== x fie? w: [280 w%:[100.0 Cel | i} 


y: fea H: [230 H% : [100.0 Layer: 8 


Napkin pict 


Using a Custom Color Palette 

The project we are creating was designed to 
run on 256-color displays. The graphics for 
this project were rendered using a custom 
color palette. The color palette has been 
saved as a CLUT file that we can import into 
our project. 


¢ Ensure that Modifier Palette Group 2 is vis- 
ible. To do this, select the View menu and 
look at the Modifier Palettes cascading 
menu item. If there is a checkmark next to 
Group 2, that palette is already visible. If 
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there is not a checkmark, select the Group 
2 menu item to display the palette. 


* Drag a color ta- 


ble modifier 


from this palette 


and drop it onto 


the scene (i.e., 
the background 


Napkin.pict ele- 
— Color Table 


ment, not the Modifier 


QuickTime vid- 
eo element). 


Shot Tip 


Hold down the control key while moving the 
cursor over the modifier palette to view each 
modifier's name. 


* Double-click the color table modifier on 
the scene to open its dialog box. 


The highlighted text at the top of the modifier 
dialog is the default name of this modifier. 


¢ Rename the modifier “mTutorial.clut.” It’s 
a good authoring habit to give your modi- 
fiers unique and descriptive names. 


¢ From the dialog’s Color Table pop-up 
menu, choose the Link file option. A stan- 
dard file selection dialog appears. Choose 
the file mTutorial.clut from the CLUTs 
folder found within the mTutorial Media 
folder. Your Color Table Modifier dialog 
should now look like the one shown Figure 
7.2. Click the “OK” button to dismiss the 
Color Table Modifier dialog. 


=> Color Table Modifier 


| Tutor ial.clut 


Apply when: 


Scene Started [x] 


Color Table: 


frtutoritem J [=] 


Specifications 


Figure 7.2 A typical modifier configuration dialog. 


i Tip 


To view the effect of a color table that has been 
applied to a scene while in edit mode, choose 
the name of the color table from the View 
menu's Preview Color Table submenu. 


Test the Project 

So far, we’ve worked on the project in edit 
mode. We can switch to runtime mode to view 
the project as a user would see it. Press #-T 
to run the project. The screen should go 
black, then the napkin picture appears and 
the QuickTime movie plays over the top of it. 
To switch back to edit mode, press #-T 
again. 
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Changing an Element's Properties 

For the most part, the QuickTime movie ele- 
ment behaves just as we want it to—it plays 
through one time, then stops. The element 
can be customized in numerous ways 
through its Element Info dialog. Use the mov- 
ie’s Element Info dialog to adjust the movie’s 
volume. 


* Double-click the mSketch.MooV element 
to open its Element Info dialog, or display 
the dialog by selecting the mSketch.MooV 
element and then choosing Element Info 
from the Object menu. 


¢ In the Element Info dialog, change the val- 
ue of the Volume setting to 80. Now when 
the project is played, the volume of the 
movie will be 80% of its maximum volume. 


* Click “OK” to accept this change and dis- 
miss the Element Info dialog. 


Run the project again by pressing #-T. Press 
36-T again to return to edit mode. 


Saving the Project 
Now would be a good time to save your 
work. 


* Choose the Save option from the File 
menu (or press #-S). 


¢ Name and store the project as you would 
any other application file. 


* If, at any point, you want to restore the 
project to a previously-saved version, select 
Open from the File menu to load the saved 
file. 
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Using a Modifier to Change the Scene 
When the movie is finished playing, we want 
our project to continue to the next scene. The 
Change Scene modifier can be used to add 
this type of functionality to our project. We'll 
also configure our introductory scene so that 
if the user clicks before the movie is done, the 
scene will change. 


¢ Drag a Change 


Change Scene— 
Modifier 


Scene modifier 
from the Group 


2 modifier pal- 
ette and drop it 


on the movie ele- 
ment. The modi- 


fier icon attaches 


itself to the up- 


per left corner of 


the movie ele- 


ey ay OW se: It 


ment. 


* Double-click the modifier icon to display 
its configuration dialog. 


* Change the name of this modifier. Change 
the text of the modifier’s name field (which 
currently reads “Change Scene Modifier”) 
to To Next Scene. When naming modifi- 
ers in your own projects, use concise, de- 
scriptive names that relate to the function 
of the modifier. 


Now use the Execute When pop-up menu to 
specify the message that will activate this 
modifier. 


* Open the Execute When pop-up menu and 
select Play Control-At Last Cel as shown 
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in Figure 7.3. Now when the movie ends, a 
scene change will occur. 


= Change Scene 


Execute When: 


| Specifications 
@ Next scene in subg 
© Previous scene in 
© Specify Scene: 


D) Add to destination 
1D Add to return list 
oO Wrap around 


Play Control Played 
Stopped 


Motion 
Transition 


Paused 
Unpaused 
Toggle Pause 


Parent 


> 
b 
» 
Scene » 
» 
b 
> 
b 


At First Cel 
At Last Cel 


Shared Scene 
Project 


Get Attribute 
Set Attribute 


Figure 7.3 Configuring the “Execute When” field of 
a Change Scene Modifier 


The Specifications area of the Change Scene 
Modifier dialog is used to choose the destina- 
tion scene to which to change. Since we want 
to change to the next scene, and this is the de- 
fault setting, we won’t change it. 


* Accept the changes to the modifier by 
clicking the OK button. The Change Scene 
Modifier dialog disappears. 


Now let’s create a Change Scene modifier that 
changes to the next scene if the user clicks on 
the screen while the introduction is still play- 
ing. 


* Select the change scene modifier on the 
mSketch.MooV element and press #-D to 
duplicate it. Drag the new copy from the 
movie element and drop it on the scene 
(i.e., drop the modifier outside the bounds 


of the mSketch.Moov element so that it at- 
taches to the scene element). 


* Double-click the new change scene icon to 
display its configuration dialog. 


¢ Use the Execute When pop-up menu to se- 
lect Mouse-Mouse Up. Now this modifier 
will activate when the user clicks on the 
scene. 


* Click OK to accept the change. The dialog 
disappears. 


Now we will create the next scene in the 
project. 


Create a New Scene 

To create a new scene in the layout view, use 
the third pop-up on the right at the top of the 
window (where it now reads “Napkin.pict”). 
The pop-up lists all scenes in the current sub- 
section and a “New Scene” option that can be 
used to create new scenes. New Scene always 
appears as the last item in this pop-up. 


* Select New Scene from the scene pop-up. A 
new, empty scene (named “Untitled 
Scene”) is created. The layout window 
changes to display this new scene. 


Let’s link a background image to this new scene. 
* Click on the scene to select it. 


* Choose the Link Media-File option from 
the File menu. A standard file selection di- 
alog appears. 


* Select the mBackground.pict file from the 
PICTs folder within the mTutorial Media 
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folder. The mBackground.pict file fills the 
scene. Note also that the name of our new 
scene changes to “mBackground.pict”. 


Let’s see the effect of adding this scene. 


* Return to the previous scene by using the 
scene pop-up to select “Napkin. pict” or 
click once on the left scene navigation ar- 
row at the top of the layout window. 


* Now run the project (press 36-T) and view 
the changes. Notice that when the movie 
ends, or when you click on the first scene, 
the scene changes to the next scene. Press 
36-T again to return to edit mode. 


Adding a Scene Transition 

When the scene changes, it simply jumps 
from the first scene to the next, without any 
sort of transition effect. Let’s create one. 


¢ Drag a Scene Transi- 


tion modifier from 
Scene 


Transition— 
Modifier 


the Group 2 modifier 
palette and drop it 
onto the Napkin. pict 


scene. 


* Double-click the 
modifier to display 


its configuration dia- 
log. 


* Change its name 
from Scene Transition Modifier to Random 
Dissolve. 


¢ Select Scene Ended from the Enable When 
pop-up. 


Creating the Second Scene 


¢ Select Random Dissolve from the Transi- 
tion pop-up. 


* Set the value of the Rate option to 30. 


* Click the OK button to close the Scene 
Transition Modifier dialog. The dialog dis- 
appears. 


Press #6-T to run the project. Notice that 
when the scene changes, the first scene ap- 
pears to “dissolve” into the next. Press -T 
again to return to edit mode. 


CREATING THE SECOND SCENE 


Now let’s add elements to the second scene. 


* Navigate to the second scene by selecting 
mBackground.pict from the scene pop-up 
(the third pop-up from the right at the top 
of the layout window) or click the right 
navigation arrow ({m] also found at the top 
of the layout window). 


In this scene, we will build a reasonably com- 
plex “puzzle” using animated elements as the 
puzzle pieces. The puzzle pieces will be drag- 
gable by the user and programmed to “snap” 
into place if they are within a 15 pixel radius 
of their destination coordinates. Once they 

are in place, the pieces are no longer dragga- 


ble. Once all of the puzzle pieces are in place, 
they become animated. 


Adding a Puzzle Piece to the Scene 

In this section, we'll use the Asset Palette to 
manipulate media that has been linked to the 
project. 
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¢ Select Asset Palette from the View menu. 
The Asset Palette appears. 


Asset Palette 


(Color Table PICT 


ImSketch Moo¥ Tutorial.clut imBackground pict! 


This palette shows thumbnail images of all of 
the media assets currently linked to the 
project. 


Previously, we had linked media directly to 
graphic elements in the project. Now, howev- 
er, we will import media without having an 
element selected. The media will be linked to 
the project, but won’t appear in the layout 
window—it will only be added to the Asset 
Palette. 


* Link all the media files contained in a di- 
rectory into the project. Choose the Link 
Media-Folder option from the File menu. 
A standard file selection dialog appears. Se- 
lect the mTOONSs folder found within the 
mTutorial Media folder. Click on the but- 
ton at the bottom of the folder selection dialog 
when the name “mToons” appears in that 
button. 


Also link one more file into the project. 


* Select the graphic tool from the tool pal- 
ette. 


* Create a new graphic element by dragging 
the tool somewhere on the scene. 


* Choose the Link Media-File option from 
the File menu. A standard file selection di- 


alog appears. Select the file mPiece 1.pict 
found in the PICTs folder in the mTutori- 
al Media folder. The picture appear in the 
graphic element. Notice that the contents 
of the Asset Palette are also updated after 
linking the media. You may need to resize 
the Asset Palette or use its scroll bar to see 
the new media icon. 


* We only want this new element in the Asset 
Palette right now—it is not actually needed 
in the scene. Delete the graphic element 
from the scene by selecting it (if it is not al- 
ready selected) and choosing Cut from the 
Edit menu. 


The media assets on the Asset Palette can be 
dragged from the palette and dropped into 
our project. Let’s add one of the puzzle pieces 
to the project. 


¢ Drag the mToon element mPiece 2.toon 
from the Asset Palette and drop it onto the 
mBackground.pict scene. 


Programming the First Puzzle Piece 

Since all of our puzzle pieces need to behave 
in a similar fashion, we will program one ele- 
ment first and then create an alias of that pro- 
gramming that we can copy onto all the other 
puzzle pieces. 


Aliasing requires additional explanation. 
When programming the puzzle, we are going 
to create a single behavior that can then be 
aliased and used on all of the puzzle pieces. 
The alias feature allows you to create copies of 
programming that can be used on multiple 
elements in a project. Updates made to one 
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copy are made to all of the aliased versions si- 
multaneously. 


Creating the Puzzle Piece Behavior 

Let’s begin programming the first puzzle 
piece by adding modifiers to it. The first type 
of modifier we'll add is a behavior. 


¢ Ensure that Modifier Palette Group 1 is vis- 
ible. Select the View menu and look at the 
Modifier Palettes cascading menu item. If 
there is a checkmark next to Group 1, that 
palette is already visible. If there is not a 
checkmark, select the Group 1 menu item 
to display the palette. 


* Drag a behavior 


Behavior — 
Modifier 


modifier from the 

Group | modifier 

palette and drop it 
onto the puzzle 


piece mPiece 2.toon 
in the layout win- 
dow. The behavior 
modifier is a special 


modifier that can 


contain other modi- 


Dag eeooa 


fiers. 


* Double-click the be- 
havior modifier to display its configuration di- 
alog. 


¢ Change the name of the behavior from Be- 
havior to Puzzle Piece. Do not close the 
behavior dialog. 
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Making the Puzzle Piece Transparent 
Now let’s add the programming that will 


make the piece transparent to the back- 
ground. 


* Drag a graphic mod- 


ifier from the Group 
2 modifier palette 


and drop it into the 
open behavior win- 
dow. 


* Double-click the 
graphic modifier to 


Graphic— 
Modifier 


open its configura- 
tion dialog. 


i 
a 
a 
a 
| 


* Change the graphic 
modifier’s name from Graphic Modifier to 


Transparent Ink. Its purpose is to apply a 
background transparent effect to the ele- 
ment with which it is associated. 


* Use the Ink pop-up menu to select the 
Background Transparent option. 


* Close the graphic modifier dialog to accept 
the change. 


The behavior dialog should now look like the 
one shown in Figure 7.4. 


Making the Puzzle Piece Draggable 

By adding another modifier to the behavior, 
we can make the puzzle piece draggable by 
the user. 
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* Drag a drag mo- 
tion modifier from 
the Group 2 modi- 
fier palette and 
drop it into the 


Drag Motion— 


Puzzle Piece be- Modifier 


havior window. 


Since we're using 
just one drag motion 
modifier, we'll use its 


default name. No 
special configura- 


tion of this modifier is necessary at this point. 


Use #-T to switch to runtime mode and try 
dragging the puzzle piece around. Note that 
the animation will be running, but we'll 
pause it in the next few steps. When finished, 
press #-T again to return to edit mode. 


SS mututorial2 : Behavior Se 
a Piswtean 
Enable when: Disable when: 
Parent Enabled +4 [von ~j 
Parent Enabled a 
Bo 
Transparent Ink 
i] 
<q il >| 


Figure 7.4 The Puzzle Piece behavior window with 
one modifier 


Changing Other Aspects of the Puzzle Piece Be- 
havior 

Since these elements are reasonably small an- 
imation files, and we want good playback 
performance, we will preload them into 
RAM. This can be accomplished by sending 
the puzzle piece a Preload command. 


* Re-open the Puzzle Piece behavior by dou- 
ble-clicking its icon. 


¢ Drag a messenger 
modifier from the 
Group | modifier 
palette and drop it 
into the Puzzle 


Messenger— 
Modifier 


Piece behavior win- 
dow. 


* Double-click the 
messenger modifier 


icon to display its 


configuration dia- 
log. 
* Change the name of the messenger from 


Messenger to Preload. 


* Use the messenger’s Execute When pop-up 
menu to select the Scene-Scene Started 
option. 


* Inthe messenger’s Message Specifications sec- 
tion, use the Message/Command pop-up to 
select the Element—Preload Media option. 


* No change needs to be made to the With 
and Destination menus. 


* Click OK to accept the changes. The Mes- 
senger dialog disappears. 
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By default, the puzzle piece animations play 
when the scene starts. However, we want the 
animations to be paused until the puzzle is 
complete. The animation can be paused by 
sending a Pause command to the puzzle 
piece. 


¢ Drag another messenger modifier from the 
Group | modifier palette and drop it into 
the Puzzle Piece behavior window. 


* Double-click the messenger modifier icon 
to display its configuration dialog. 


* Change its name to Pause. 


* Use the messenger’s Execute When pop-up 
menu to select the Parent-Parent Enabled 
option. 


* Use the messenger’s Message/Command 
pop-up to select the Play Control-Pause 
option. 


* Leave the Destination of the message as El- 
ement (this is the default destination). The 
With pop-up should also not be changed. 


* Click OK to accept the changes and dismiss 
the Messenger dialog. 


* Click the behavior’s close box to dismiss 
the Puzzle Piece behavior window. 


Note that the animation could also have been 
paused by setting the element’s “paused” at- 

tribute via the Element Info dialog. However, 
by using a messenger to pause the animation 
and placing that messenger in a behavior that 
will be used on all the other puzzle pieces, we 
have eliminated the need to individually se- 
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lect the “paused” attribute for each puzzle 
piece. 


Adding the Puzzle Snap-In Function 

Let’s now program the “snap-in” functionality 
of the puzzle piece. First, we need a way to 
store the screen coordinates of the correct po- 
sition of the puzzle piece. We can use a point 
variable to store this value. Since every puzzle 
piece will use the same (aliased) behavior, but 
will all have different final screen positions, 
the variable that contains each piece’s x and y 
coordinates must be placed outside the behav- 
ior. 


Positioning variables this way allows vari- 
ables of the same name to contain different 
values. The modifiers that access them from 
within aliased behaviors will use the correct 
variable for each element. 


Let’s add a point variable modifier to the mP- 
iece 2.toon puzzle piece. 


i 


* Drag a point variable 


modifier from the 


Group | modifier pal- 
ette and drop it on the 


mPiece 2.toon puzzle 


element. 


* Double-click the point 
variable icon to dis- ee 
Variable 
Modifier 


play its configuration 
dialog. 


BR EAB REES 


* Change the variable’s 
name from Point 
Variable to piecePosition. 
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¢ Enter 167 into the modifier’s X field and 
204 into the Y field. 


* Click OK to accept the changes and dismiss 


the Point Variable dialog. 


Adding a Miniscript Modifier to the Behavior 
The mTropolis Miniscript modifier is a spe- 
cial modifier that can execute commands 
written in a simple scripting language. This 
modifier allows you to create modifiers that 
perform complex or customized tasks. 


Here, we'll add a simple script that sets the 
puzzle piece’s position to a random position 
within the boundary of the screen. 


¢ Double-click the Puzzle Piece behavior 
icon to open its window. 


¢ Drag a Miniscript 
— Miniscript 
Modifier 


modifier from the 
Group | modifier 
palette and drop it 
into the Puzzle 
Piece behavior win- 
dow. 


Double-click the 
Miniscript modifier 
icon to display its 


configuration dia- 
log. 


* Change the modifier’s name from Miniscript 
Modifier to Random Position. 


* Use the Execute When pop-up to select the 
message Scene-Scene Started. 


¢ In the modifier’s Script text box, type the 
following script: 


-—- Set the puzzle piece toa 
-—- random position: 


set position to rnd(580), rnd(420) 


Your modifier dialog should now look like 
the one shown in Figure 7.5. 


Miniscript Modifier 


i?) [Random Position CG) 
Execute When: 
[Scene Started [x] 
Script 
I-- Set the puzzle piece to a 
I-- random position: 


set position to rnd(S80), rnd(420) 


Figure 7.5 The “Random Position” Miniscript modifier 


dialog 


The first three lines of our script are com- 
ments—the two dashes that start each line 
tell mTropolis to ignore any text that fol- 
lows on that line. Comments are not re- 
quired for the script to function properly, 
but help to make your scripts easier to read 
and debug. 


The last line is a Miniscript statement. It 
uses the Miniscript function “rnd” to gener- 
ate a random number between 0 and the 
number in parentheses for the x and y co- 
ordinates of the element. When activated, 
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this script will set the puzzle piece’s posi- 
tion to the random values generated by the 
“nd” function. 


* Click OK to accept these changes and dis- 
miss the Miniscript Modifier dialog. 


Encapsulating the Modifiers into a Behavior 

As good housekeeping, we'll encapsulate 
some of the modifiers we have created into a 
new behavior. Let’s group the modifiers that 
set the initial characteristics of the puzzle 
piece together. 


¢ Drag a new behavior from the Group 1 
modifier palette and drop it into the open 
Puzzle Piece behavior window. 


¢ This time, instead of opening the behavior 
to rename it, simply click on the behavior’s 
name shown below its icon, and enter the 
new name, Initial Settings. Click outside 
the name when you are done editing the 
name. 


* Instead of opening the new behavior’s dia- 
log, modifiers can be added to the behavior 
simply by dragging and dropping their 
icons onto the new behavior’s icon. Drag 
the following modifiers onto the Initial Set- 
tings behavior icon: the graphic modifier 
named Transparent Ink, the messenger 
named Preload, the Miniscript named Ran- 
dom Position, and the messenger named 
“Pause.” The modifier icons seem to “disap- 
pear” as they are moved into the new be- 
havior. 
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Configuring an ‘If’ Messenger to Test for the Puz- 
zle Piece Position 

Now let’s program an “if” messenger to test 
for the position of the puzzle piece. This 
modifier will compare the position of the 
puzzle piece when the user releases the piece 
to the value stored in the piecePosition point 
variable that we previously attached to the el- 
ement. 


* Drag an “if” mes- 


senger from the 


Group | modifier 
palette and drop 
it into the Puzzle 


— If Messenger 
Modifier 


Piece behavior 
window. 


* Double-click the 
messenger’s icon 
to display its con- 
figuration dialog. 


Change the name 
of the messenger from If Messenger to 
Dropped in Valid Position. 


By default, this messenger is configured to 
act on the Mouse Up message, and this is 
what we want, so we don’t need to change 
the Execute When pop-up. 


* In the “If text field, enter the following 


statement: 
((position.x < (piecePosition.x + 15)) and \ 
(position.x > (piecePosition.x - 15))) and \ 


((position.y < (piecePosition.y + 15)) and \ 
(position.y > (piecePosition.y - 15))) 


This statement evaluates to true when the 
puzzle piece is released within 15 pixels of 
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the value stored in the piecePosition point 
variable. 


¢ When these conditions are met, we want to 
send a message to the element that it has 
been released in the proper location. To do 
this, we will create a custom message (an 
author message). Highlight the content of 
the Message/Command field (do not use 
the pop-up button). Type Piece In Place 
into the field and click OK. A dialog ap- 
pears, asking if you want to create this new 
author message. Click OK on this new dia- 
log. 


Programming the Puzzle Piece when it is in Place 
Now we are ready to program the actions of 
the puzzle piece when it is dropped in place. 
A behavior will be used to store the actions 
that occur. 


¢ Drag a new behavior modifier from the 
Group | modifier palette and drop it into 
the Puzzle Piece behavior window. 


* Click on the name of the behavior that ap- 
pears below the icon and enter the new 
name, Piece in Place. 


Next we'll configure the previously-created 
drag motion modifier so that the puzzle piece 
cannot be dragged once it is in place. 


* Drag the drag motion modifier icon from 
its current position and drop it into the 
Piece in Place behavior. 


¢ Double-click the Piece in Place behavior 
icon to open its window. 


¢ In the Piece in Place window, double-click 
the drag motion icon to display its configu- 
ration dialog. 


* We want to disable this modifier when the 
piece is put in its correct place. Use the Dis- 
able When pop-up menu to select the op- 
tion Author Messages-Piece in Place. 
Now the piece will no longer be draggable 
after this message is received. 


* Click OK to confirm your changes and dis- 
miss the Drag Motion Modifier dialog. 


* Move the “Dropped in Valid Position” mes- 
senger you created previously into the 
“Piece in Place” behavior. 


We now need to add a Miniscript modifier to 
the Piece in Place behavior that moves the 
piece to its final position when it is dropped 
near, but not exactly on, the final position. 


* Drag a new Miniscript modifier from the 
Group 1 palette and drop it into the Piece 
in Place behavior. 


* Double-click the modifier to display its 
configuration dialog. 


* Name the new Miniscript modifier Piece in 
Place. 


* Use the Execute When pop-up menu to 
configure the modifier to activate when the 
Piece in Place author message is received. 
Select the Author Messages-Piece in 
Place option from the menu. 


* In the Script text field, enter the following 
script: 
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—- Snap piece into place: 
set position to piecePosition 


-—- Change cel of toon: 
set cel to 2 


* Click “OK” to close the Miniscript dialog. 
Click on the close boxes of the open behav- 
iors to dismiss their windows. 


The first line of the script moves the element 
to its exact final position in the puzzle. The 
second line changes the currently displayed 
cel of the element so that it looks different 
when it is in place in the puzzle. 


You may want to test your programming up 
to this point. Press #8-T to switch to runtime 
mode. When the puzzle appears, drag the 
puzzle piece and drop it near its correct posi- 
tion (this piece belongs on the left-side slant- 
ed line of the “M”). You should notice it snap 
into place when you release it. Once it does, 
you will no longer be able to drag the piece 
around. Press #-T to return to edit mode. 


Adding the Snap Sound 
A sound effect would be nice feedback to no- 
tify the user that the puzzle piece is in place. 
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* Drag a sound effect 


modifier from the 


Group 2 modifier 


palette and drop it 
into the Piece In 


Place behavior win- Sound 
d Effect — 
OW: Modifier 


¢ Double-click the 
sound modifier to 


display its configura- 


tion dialog. 
¢ Name the modifier Piece in Place Sound. 


¢ Use the Execute When pop-up to select the 
message that triggers the sound. Select Au- 
thor Messages-Piece in Place. 


* Use the dialog’s Sound pop-up menu to se- 
lect a sound to be played. Select Link 
File... from the menu. A standard file se- 
lection dialog appears. Select the sound file 
Piece in Place.aiff located in the AIFFs fold- 
er found in the mTutorial Media folder. 


Click the Preview button to preview the 
sound. Click OK to accept your changes 
and dismiss the Sound Effect Modifier dia- 
log. 


Disabling the Piece in Place Behavior 

One of the most powerful capabilities of behav- 
iors is that they can be made “switchable”. That 
is, they can be turned “on” or “off” by messages, 
just like any other modifier. When a behavior is 
deactivated, all of the modifiers inside that be- 
havior are also deactivated. 


In our project, it makes sense to deactivate the 
“Piece in Place” behavior once a piece is actually 


7.16 Tutorial 


in place. By switching this behavior off, we can 
insure that the project doesn’t keep checking for 
puzzle pieces that are already in their proper 
places. 


Let’s add one last modifier to the Piece in 
Place behavior. 


¢ Drag a new messenger modifier from the 
Group | modifier palette and drop it into 
the Piece in Place behavior window. 


* Double-click the new messenger to display 
its configuration dialog. 


¢ Rename the messenger to Disable Checks. 


* Use the dialog’s Execute When pop-up to 
select the Author Messages-Piece in Place 
message. 


* Highlight the text in the Message/Com- 
mand menu and type Disable Checks. 


* Click OK. A dialog appears, asking if you 
want to create the new author message. Click 
OK. 


* In the “Piece in Place” behavior window, 
select the Switchable checkbox found next 
to the behavior name. 


* Two previously inactive pop-up menus be- 
come accessible. Now the behavior has En- 
able When and Disable When pop-up menus 
that can be used to specify the messages that 
activate and deactivate this behavior (and all 
of the modifiers contained within it). 


* Verify that the behavior’s Enable When 
message is Parent Enabled, then use the 
Disable When pop-up menu to select Au- 


thor Messages-Disable Checks. Now the 
functionality of this behavior will be dis- 
abled when the piece is in place. 


Your Piece in Place behavior window should 
now look something like the one shown in 
Figure 7.6. We are finished modifying the 
Piece in Place behavior, so close the window 
by clicking its close button. 


Keeping Track of the Puzzle Pieces in Place 
Let’s program a behavior that keeps track of 
the number of puzzle pieces in place, so that 
when the sixth piece is dropped in place, the 
entire puzzle will come alive. 


* Start by dragging a new behavior modifier 
from the Group 1 modifier palette and 
dropping it into the “Puzzle Piece” behav- 
ior window. 


¢ Double-click the new behavior’s icon to 
display its configuration window. 


¢ Change the name of the behavior to Puzzle 
Status. 


¢ Drag an integer variable from the Group 1 
modifier palette and drop it in the Puzzle 
Status behavior window. 


¢ Double-click the integer variable’s icon to 
display its configuration dialog. Change 
the name of the variable to pieceCount. 
Leave its value field set to 0 (the default). 
This variable will be used to store the num- 
ber of puzzle pieces that are in place. 


* Click OK to dismiss the variable’s dialog. 
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* Drag another integer variable into the Puz- 
zle Status behavior and name it totalPiec- 
es. 


¢ Set the variable’s value to 6. 


We're going to use copies of these variables in 
each of the puzzle piece elements, so now 
we'll make these variables into “aliases”. 


¢ Select both variable icons in the Puzzle Sta- 
tus behavior window (using Shift-click or 
by simply dragging the pointer across the 
variables to “marquee” select them). 


* Choose Make Alias from the Object menu. 
Making these variables aliases means their 


¢ Click outside the variables to deselect 
them. You will notice a visual change to the 
icons. 


Whenever the puzzle scene is first displayed, 
we want to make sure that the pieceCount 
variable is initialized to zero. 


¢ Drag a Miniscript modifier from the Group 
1 modifier palette and drop it into the Puz- 
zle Status behavior window. 


* Double-click the Miniscript modifier to 
display its configuration dialog. 


* Change the modifier’s name to Reset 
pieceCount. 


values will be the same wherever they oc- ©. 
* Use the modifier’s Execute When pop-up 


cur in your project. 
yo ee) to select the Scene-Scene Started message. 


* In the Script text field, enter the following 
script: 


2 SSS muytutorial2 : Piece in Place 


3 Eilswitchate 


Enable when: Disable when: 


Parent Enabled ial Pisse Ne Checks ia | 


Parent Enabled 
Piece in Place f 


Mouse Up TT 


Disable Checks 
4 (a) | | 


Drag Motion Modifier 


it 


Dropped in Valid Position 


Gl (2) 


Piece in Place 


a] (3) 

Piece in Place Sound | 
Ell (4) 
Disable Checks 


Figure 7.6 The completed Piece in Place behavior 
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—- Reset the count of pieces 
-—- in place: 
set pieceCount to 0 

* Click OK to confirm the changes and dis- 
miss the dialog. Now each time the user ar- 
rives at the puzzle scene, the pieceCount 
variable is set to 0, meaning that no pieces 
are currently in place. 


Notifying the Environment that the Puzzle Is 
Complete 

Now we need to add functionality that up- 
dates the pieceCount counter each time a 
puzzle piece is put in place. When the 
counter reaches the total number of pieces, a 
message will be sent to the environment that 
the user has finished the puzzle. 


Before we add another modifier, let’s create a 
new author message. This time, use the Au- 
thor Messages window to create the author 
message. 


* Select Author Messages Window from 
the View menu. The Author Messages win- 
dow appears. 


* Click the New Message button in the Au- 
thor Messages window. An untitled mes- 
sage appears below the two 
previously-defined messages shown in the 
window. 


* Double-click the untitled author message 
and change its name to Puzzle Complete. 


* Close the Author Messages window by 
clicking its close button. 


Now we'll return our attention to the “Puzzle 
Status” behavior. 


* Drag a new Miniscript modifier to the Puz- 
zle Status behavior window. 


* Double-click the modifier’s icon to display 
its configuration dialog. Change its name to 
Add To Counter and configure the Exe- 
cute When field to execute on Author 
Messages-Piece in Place. 


¢ Enter the following script in the Script text 
field: 


—- Increase the pieceCount: 
set pieceCount to pieceCount + 1 


-—- Is the puzzle complete? 

if pieceCount = totalPieces then 

send "Puzzle Complete" to \ 
element's parent 

end if 


The set statement in the script increases 
the count of puzzle pieces by one. The rest 
of the script (the 1£ statement) is a simple 
conditional statement. When the number 
of pieces in place equals the total pieces in 
the puzzle, the “Puzzle Complete” author 
message is sent to the element’s parent, 
which is the scene. 


* Click OK to dismiss the Miniscript Modifi- 
er dialog. 


¢ Close the “Puzzle Status” behavior window 
by clicking its close box. 


Animating the M Machine 

Now we'll program the actions that are to 
take place when all the puzzle pieces have 
been put in place. 
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Add a new behavior modifier to the “Puzzle 
Piece” behavior. 


Double-click the behavior icon to display its 
configuration window. 


Change the name of the behavior to Puzzle 
Complete. 


Select the Switchable box at the top of the 
behavior window. The Enable When and 
Disable When pop-ups become available. 


Use the Enable When pop-up menu to se- 
lect Author Messages-Puzzle Complete. 
Use the Disable When pop-up menu to se- 
lect Parent-Parent Enabled. 


Add a Miniscript modifier to the “Puzzle 
Complete” behavior window. 


Double-click the Miniscript modifier to 
display its configuration dialog. 


Change the Miniscript modifier’s name to 
Set Animation Specs. 


Use the Execute When pop-up menu to se- 
lect the Parent-Parent Enabled message. 


Enter the following script in the Script text 
field: 


—- Set the range of cels to play: 
set range to 2 thru 9 


—- Set the rate of play: 
set rate to 15 


Now when the animation plays, it will only 
play cels 2 through 9 at a rate of 15 frames 
per second. 
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¢ Click the OK button to dismiss the Mini- 
script Modifier dialog. 


¢ Drag a messenger modifier from the Group 
1 modifier palette and drop it into the 
“Puzzle Complete” behavior window. This 
messenger will be configured to activate 
the animation. 


* Double-click the messenger icon to display 
its configuration dialog. Change the mes- 
senger’s name to Play Animation and con- 
figure it to execute on the Parent-Parent 
Enabled message using the Execute When 


Pop-up. 


* Use the Message/Command pop-up menu 
to select the Play Control-Play command. 
When sent to the element, this command 
will make its animation begin playing. 


* Click OK to close the messenger dialog and 
confirm the changes. 


* Close the “Puzzle Complete” behavior win- 
dow by clicking its close button. 


¢ Close the “Puzzle Piece” behavior window 
by clicking its close button. 


If you haven’t saved your project in a while, 
now is a good time to select Save or Save As 
from the File menu. 


Adding and Programming the Other Puzzle 
Pieces 

We have just created a reusable software 
component that we are going to apply to all 
of the puzzle pieces. Let’s add them now. 
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* If it is not already visible, select Asset Pal- 
ette from the View menu. The Asset Palette 
appears. Also, select Alias Palette from the 
View menu. The Alias Palette appears. Note 
that the two aliases we created previously 
are shown on the Alias Palette. 


¢ Drag the rest of the puzzle pieces (mPiece 
l.pict, mPiece 3.mToon, mPiece 
4.mToon, mPiece 5.mToon, and mPiece 
6.mToon) from the Asset Palette into the 
layout window. 


* Select (click on) the “Puzzle Piece” behav- 
ior icon found on the mPiece 2.toon ele- 
ment. 


* Choose Make Alias from the Object menu. 
Notice that the “Puzzle Piece” behavior is 
added to the Alias Palette. 


* Now distribute this modifier to the five 
other puzzle pieces by dragging the aliased 
Puzzle Piece behavior icon from the Alias 
Palette and dropping it onto each piece. As 
you drop the alias on each piece, notice 
how each piece’s background becomes 
transparent. Each piece is inheriting the 
properties defined by the Puzzle Piece be- 
havior. 


* Copy the point variable (named piecePosi- 
tion) from the mPiece 2.mToon element to 
each of the other puzzle pieces. Don’t con- 
fuse this variable with the two on the Alias 
Palette. Option-drag the point variable 
from mPiece 2.mToon to each piece. Using 
Option-drag makes a copy of the variable 
instead of moving the original. 


Now we have to configure the point variables 
on each of the newly-added puzzle pieces 
with the correct positions. 


¢ For each new puzzle piece, double-click 
the point variable on that piece to display 
its configuration dialog. Change the X and 
Y values to the appropriate value shown in 
Table 7.1. The value of mPiece 2.toon has 
already been set, but is shown below for 
completeness. 


Element Name| X | Y 


mPiece l.pict |242|83 

mPiece 2.toon |167)204 
mPiece 3.toon |294]199 
mPiece 4.toon |167|241 
mPiece 5.toon |356]237 
mPiece 6.toon |257]166 


Table 7.1: piecePosition values for each puzzle piece 


Changing the Layer Order of Pieces 

One final consideration for the integration of 
these puzzle pieces is their layer order. Layer 
order refers to the order in which elements in 
a scene are drawn on the screen. Elements 
will draw on top of one another according to 
their layer order. Higher layer order numbers 
draw “in front” of lower numbers. 


We can use the Object Info Palette to set each 
piece’s correct layer order. 


¢ If it is not already displayed, open the Ob- 
ject Info Palette by selecting Object Info 
Palette from the View menu. 
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* Select each puzzle piece, and enter its cor- 
rect layer order number, as shown in 
Table 7.2, in the “Layer” field of the Object 
Info Palette. When the pieces have been as- 
signed the layer orders shown in Table 7.2, 
the completed “M” machine will look its 
best. 


Asset Name |Layer 


mPiece 4.toon 


mPiece 1.pict 


mPiece 2.toon 


mPiece 6.toon 


mPiece 3.toon 


a uf BT wl rm] 


mPiece 5.toon 


Table 7.2: Layer order numbers for each piece 


Now press 36-T to run the project. Each piece 
should snap into place and make the “clang” 
sound when dropped into its proper posi- 
tion. When all the pieces have snapped in, 
the pieces of the “M” should become animat- 
ed. Press #8-T to return to edit mode. 


NAMING STRUCTURAL ELEMENTS 

As with any mTropolis element, it is good prac- 
tice to give descriptive names to all of the sec- 
tions and subsections of a project. These names 
will make the project much easier to under- 
stand, especially for others. We're going to use 
the mTropolis structure view to rename the sec- 
tion and subsection used in this project. 


* Select Structure Window from the View 
menu. The Structure window appears. 


Naming Structural Elements 


¢ Inthe structure window, click the text label 
that reads Untitled Section. When the 
field becomes editable, change the name to 
mTutorial. 


* Each level of the hierarchy shown in the 
structure view has an “Open/Close” trian- 
gle to its left. If the triangle is pointing to 
the right, there are move levels in the hier- 
archy that can be revealed by clicking the 
triangle. When clicked, the triangle points 
downward and the next level of the hierar- 
chy is revealed. We want to reveal the level 
below the mTutorial section, so click the 
triangle next to it. The Untitled Subsection 
level is revealed. 


¢ Click the text label that reads Untitled 
Subsection. When the field becomes edit- 
able, change the name to mPuzzle. 


Your Structure window should now look like 
the one shown below. 


ADDING SOUND 

One final touch will make our puzzle more 
satisfying: a sound that plays when the puzzle 
is complete. Previously, we used a sound mod- 
ifier to play the “Piece in Place” sound. How- 
ever, sound media can be mTropolis objects, 
just like graphical media. In this section, we'll 
add a sound element to the puzzle. Sound ele- 
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ments can only be added to a project in the 


structure view, as they have no visual repre- 


sentation in the layout view. 


In the Structure window, click on the 
open/close triangle next to the mPuzzle 
subsection to reveal our project’s scenes. 


Now click on the open/close triangle next 
to the scene named “mBackground.pict”. 
Icons for the elements of that scene (our 
puzzle pieces) appear in the list. 


To add a new sound object, select (click 
on) the mBackground.pict element and 
choose New Sound from the Object menu. 
A sound element icon appears below the 
mToon icons. 


Make sure that the sound icon is selected 
and choose Link Media-File from the File 
menu. A standard file selection dialog ap- 
pears. Select the file Puzzle Complete 
Loop.aiff found in the AIFFs folder with- 
in the mTutorial Media folder and click 
the “Link” button. The name of the sound 
element icon changes to reflect the name of 
the media. The Structure window should 
now look like the one shown in Figure 7.7. 


Double-click the sound icon to display its 
Element Info dialog. In the dialog’s Initial 
State section, select the Paused and Loop 

options. 


Click OK to confirm the changes and close 
the dialog. 


Now we'll program the sound to start playing 


when the puzzle is completed. 


mytutorial2 : Structure 
7 tr my tutorial2 
rr mTutorial 
[ta mPuzzle 
[BB] Untitied Shared Scene 
3" Napkin pict 
3" mBackground. pict 
mPiece 2.mToon 
| mPiece 1 pict 
mPiece 3.mToon 
mPiece 4.mToon 
mPiece S.mToon 
mPiece 6.mToon 


wr 
vw 
b 
b 
— 
b 
b 
b 
R 
D 
b 


Puzzle Complete Loop.aiff 


Figure 7.7 Adding a sound element to the structure 
window 


Drag a messenger onto the sound icon. The 
icon will seem to “disappear” into the 
sound icon. Click the sound icon’s open/ 
close triangle to reveal the next level of the 
structure hierarchy—the sound element’s 
modifiers. Now the Messenger icon is visi- 
ble. 


Double-click the Messenger icon to display 
its configuration dialog. 


Change the messenger’s name to Play 
when Puzzle Complete. 


Use the Execute When pop-up to select 
Author Messages-Puzzle Complete. 


Use the Message/Command pop-up to se- 
lect the command Play Control-Play. Now 


Adding Sound 


mTropolis Developer Guide 7.23 


when activated, this modifier will cause the 
sound element to begin playing. 


* Click OK to confirm the changes and dis- 
miss the Messenger dialog. 


Press #-T to run the project and hear the dif- 
ference when the puzzle is completed. Press 
36-T to return to edit mode. 


THE CREDITS SCENE 


After all this work, it’s time for some self rec- 
ognition. Making up your own credits screen 
is a good start. We are going to create a sim- 
ple credit roll in a new subsection of the 
project. 


* Create a new subsection by choosing the 
New Subsection option from the Subsec- 
tion pop-up on the Layout window. This 
menu is the second menu from the left at 
the top of the layout window (its label cur- 
rently reads “mPuzzle”). A new “Untitled 
Subsection” is created. The layout window 
updates to show the subsection’s “Untitled 
Scene”. 


¢ In the Structure window, note that a new 
Untitled Subsection icon appeared at the 
bottom of the window. Click the name of 
the new subsection and change it to Cred- 
its. 


* Click on the subsection’s open/close trian- 
gle to reveal its scenes. 


¢ Highlight the name of the Untitled Scene 
and change it to My Credits. 


The Credits Scene 


Now let’s return our attention to the Layout 
window and create some text for our credits. 


* Click on the scene in the Layout window. 


* Select the text tool (the one that looks like 
the letter “A”) from the tool palette. The 
cursor changes to an I-beam with a sma 


iy 


square next to it. 


* Create a text field by dragging in the layout 
window. Make the text element fairly large, 
so you can enter a large amount of self-con- 
gratulatory text. The outline of the new text 
element appears in the window. 


* Notice that when you move the cursor over 
the text element, the cursor changes to a 
simple I-beam. Click inside the text ele- 
ment to put an insertion point in the ele- 
ment. A flashing cursor appears. 


¢ Type the text that you want to appear in the 
credits. For example: 


This Tutorial Created by: 
Happy M. User 
mFactory 

1440 Chapin Ave. #200 
Burlingame, CA 94010 


When you are finished entering your text, 
select all of the text by dragging over it with 
the I-beam cursor. Now you can select var- 
ious text options from the Format menu. 
Pick a font, size, style, and alignment that 
appeals to you. 


¢ Return to the tool palette and choose the 
selection tool (the arrow). The cursor 
changes back to an arrow. 
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¢ Double-click on the new text element to 
display its Element Info dialog. Change the 
element’s name to Credits Text. 


* Click OK to confirm your change and dis- 
miss the Element Info dialog. 


We should now change the color of our text 
so that it will show up against the default 
black background. 


¢ Make sure that the text element is selected. 


* Select a new color for the text by clicking 
and holding the cursor over the foreground 
color swatch in the tool palette. A palette 
appears and the cursor changes to an “eye- 
dropper”. Drag the eyedropper to a color in 
the palette and release the mouse button to 
select a color as shown below. 


Notice that a graphic modifier icon appears 
on the text element. Selecting colors from the 
tool menu is equivalent to configuring a 
graphic modifier. 


We should also make the background of the 
text element transparent. 


¢ Make sure that the 
text element is se- 
lected and click 
on Ink in the tool 
palette. A pop-up ackground Matte 

Invisible 

menu appears. Se- Ghost 

Blend 

Chameleon Light 

Chameleon Dark 


Transparent 
Reverse Copy 


ink LY Copy 


Background Transparent 


lect Background 
Transparent as 


Reverse Ghost 
Reverse Transparent 


the ink option. 


Now let’s modify the text element so that it 
scrolls up and off the screen. To do this we 
will use a vector motion modifier. This mod- 
ifier works in conjunction with the vector 
variable. 


* Drag a vector variable 


from the Group 1 


modifier palette and 


drop it onto the text 
element. 


¢ Double-click the 
vector variable icon 


; : : Vector 
to display its config- yi ble — 
uration dialog. Modifier 


* Change the variable’s 
name to Up. Type 90 
in the Angle field and 
0.8 in the Magnitude field. 


* Click OK to confirm the changes and close 
the dialog. 


* Drag a vector motion modifier from the 
Group 2 modifier palette and drop it onto 
the text element. 
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* Double-click the vector motion modifier 
icon to display its configuration dialog. 


* Change the modifiers name to Move Up. 


* Use the Execute When pop-up to select the 
Scene-Scene Started message. 


* Use the Vector pop-up to select the name of 
the vector variable associated with this vec- 
tor motion. Select the Credits Text-Up op- 
tion. 


* Click “OK” to dismiss the Vector Motion 
dialog. 


Now press #-Y to run the project from this 
scene (86-T runs the project from the very 
first scene). The text element should rise from 
its starting position to the top of the screen. 
Press #6-Y again to return to edit mode. 


The effect is interesting, but you might want 
some action to take place once the text leaves 
the screen. Let’s use a boundary detection 
messenger. 


* Drag a boundary detection messenger from 
the Group | modifier palette and drop it 
onto the text element. 


* Double-click the boundary detection mod- 
ifier icon to display its configuration dialog. 


* Change the name of the modifier to Detect 
Leaving Top. 


¢ In the Detect Boundaries of Element’s Parent 
section, check only the “Top” checkbox. The 
“Bottom”, “Left” and “Right” options should 
be unchecked. 


The Credits Scene 


¢ In the Detect Element section, choose the 
“Once Exited” and “On first detection” ra- 
dio buttons. 


¢ In the Message Specifications section, use 
the Message/Command pop-up to select 
the Project-Close Project command. Use 
the Destination pop-up to select Project as 
the destination for the command. 


* Click OK to confirm the changes and dis- 


miss the Boundary Detection Messenger di- 
alog. 


In the layout window, you might want to po- 
sition the text element slightly below the bot- 
tom of the frame of the scene. When the text 
scrolls up it will look like a credit roll like you 
might see at the end of a movie. 


Another nice thing to do is to give the user 
the ability to abort the play of the credits. 


* Drag a messenger modifier from the Group 
1 modifier palette and drop it on the My 
Credits scene. 


* Double-click the messenger icon to display 
its configuration dialog. 


* Change the name of the messenger to 
Close Title. 


* Leave the Execute When message set to its 
default (Mouse Up). Use the Message/ 
Command pop-up to select Project—Close 
Project. Use the Destination pop-up to se- 
lect Project. Now, if a user clicks on the ti- 
tle scene before the credits have finished 
rolling, the project just ends. 
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* Click OK to dismiss the dialog. 


Using the Shared Scene 

You might have noticed that even though we 
have created a fully-functional credits scene, 
there’s no way for it to be activated from ear- 
lier scenes in the project! 


We'll create a button on the shared scene that 
activates the title roll. Putting the button on 
the shared scene will make it available to all 
scenes within a subsection. 


* Use the controls at the top of the layout 
window to navigate to the shared scene of 
the “mPuzzle” subsection. To do this, select 
mPuzzle from the subsection pop-up 
menu (the second pop-up from the left that 
currently reads “Credits”). The layout win- 
dow changes to show the mPuzzle subsec- 
tion’s first scene, which just happens to be 
the Untitled Shared Scene that we’re inter- 
ested in. 


* Select the graphic element tool from the 
tool palette and create a new graphic ele- 
ment by dragging on the shared scene. 


¢ Select the new element, then choose Link 
Media-File from the File menu. A standard 
file selection dialog appears. Select the file 
Manhole Quit.mToon from the mTOONs 
folder found in the mTutorial Media fold- 
er. The first cel of the Manhole mToon is 
shown in the graphic element. 


* Reposition the element by dragging it to 
the lower right area of the shared scene. 


* Double-click the element to open its Element 
Info dialog. 


¢ In the Initial State section of the dialog, en- 
sure that the Paused checkbox is checked. 


* Click OK to confirm the change and close 
the dialog. 


Let’s make the manhole’s background trans- 
parent. 


* Drag a graphic modifier from the Group 2 
modifier palette and drop it on the Man- 
hole Quit.mToon element. 


* Double-click the graphic modifier’s icon to 
display its configuration dialog. 


* Change the modifier’s name to Transpar- 
ent Ink. Use the Ink Effect pop-up to select 
Background Transparent. 


* Click on the dialog’s close box to accept the 
changes and dismiss the dialog. 


Using Libraries 

Let’s apply some functionality to the Manhole 
Quit.mToon button by adding a behavior 
from a library. Libraries can be used to store 
project components (e.g., sections, subsec- 
tions, scenes, elements, behaviors, and modifi- 
ers) in a file that is separate from the project. 


* Select Open from the File menu and 
choose the item named “Tutorial Library”. 
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The Tutorial Library appears as its own palette 
as shown below. 

o 

9} Standard Button 


i 


* Drag the behavior named Standard Button 
from the Tutorial Library palette and drop it 
on the Manhole Quit.mToon element. 


This behavior emulates a button that changes 
its appearance when it is clicked on. The be- 
havior sends out three author messages: 
“Highlight,” “Un-Highlight,” and “Execute.” 
To use this behavior, add it to a graphic that 
you want to act as a button, configure its two 
states (highlight/un-highlight) and configure 
what it does (execute). 


In this case, we have an mToon with two cels. 
One cel shows the highlighted button state, 
the other shows the un-highlighted state. To 
program the button to show the correct cel at 
the correct time, we'll use two Miniscript 
modifiers to change the cel display of the 
mToon. 


¢ Drag a Miniscript modifier from the Group 
1 modifier palette and drop it on the Man- 
hole Quit.mToon element. 


* Double-click the Miniscript icon to display 
its configuration dialog. 


* Change the name of the modifier to 
Un-Highlight. 
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¢ Use the Execute When pop-up to select Au- 
thor Messages-Un-Highlight. This author 
message was automatically created when 
you added the Standard Button behavior to 
your project. 


¢ Enter the following script in the Script text 
field: 


set cel to 1 -- Show closed manhole 
* Click OK to dismiss the dialog. 


* Now place another Miniscript modifier on 
the manhole element. 


* Double-click the new Miniscript icon to 
display its configuration dialog. 


* Change the name of the modifier to High- 
light. 


* Use the Execute When pop-up to select Au- 
thor Messages-Highlight. This author mes- 
sage was automatically created when you 
added the Standard Button behavior to 
your project. 


¢ Enter the following script in the Script text 
field: 


set cel to 2 -- Show open manhole 
* Click OK to dismiss the dialog. 


Since messengers in the Standard Button be- 
havior are already programmed to respond to 
the user’s mouse actions by sending the ap- 
propriate message, now all we need to do is 
configure the button’s action. 
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* Drag a change scene modifier from the 
Group 2 modifier palette and drop it on the 
Manhole Quit.mToon element. 


* Double-click the change scene modifier to 
display its configuration dialog. 


* Change the name of the modifier to To 
Credits. 


* Use the Execute When pop-up to select the 
Author Messages-Execute message. 


* In the Specifications section of the dialog, 
click the Specify Scene radio button. Three 
pop-up menus become active. These 
menus can be used to select the section, 
subsection and scene that will be changed 
to. Select the mTutorial section, Credits 
subsection, and My Credits scene. 


* Click OK to accept the changes and dismiss 
the Scene Change Modifier dialog. 


Your Quit button is now ready to operate. 
Use #8-T to run your project from the begin- 
ning. Note that the “manhole” button is al- 
ways available. Clicking it sends you to the 
credits page. 


Don’t forget to save your finished project one 
last time before quitting mTropolis. 


That’s it! Congratulations on your comple- 
tion of the mTropolis tutorial project! 
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Chapter 8. mTropolis Examples 


This chapter describes some of the mTropolis 
examples included in the “mExamples 
Project”. This mTropolis project is installed 
in the “mExamples” subfolder of the mTrop- 
olis folder by default when mTropolis is in- 
stalled. 


The samples included in this project demon- 
strate general mTropolis features, such as the 
use of behaviors to encapsulate programming 
code, the methods used to structure a project, 


as well as more specific topics, such as messag- 
ing and the use of variables. 


Like all mTropolis projects, each sample 


project contains reusable components. For 
example, the button logic that is encapsulat- 
ed into behaviors in the Button Gallery 
project can be saved in libraries and used 
when creating buttons in your own projects. 
Think of the components in each project as 
“clip programming” that you can use royalty- 
free. Use the projects as a source of ideas for 
planning and implementing basic title fea- 
tures. 


INSTALLATION 


If the mExamples project is not installed on 
your system, it can be installed as follows: 


* Insert the mTropolis CD into your CD- 
ROM drive. 


Installation 


* Double-click on Install mTropolis to 
launch the installer. 


* Use the installation options to perform a 
custom installation that installs just the 
“mExamples Project and Media” option. 


¢ Alternatively, simply drag the “mExam- 
ples” folder from the CD-ROM to your 
hard drive. 


RUNNING THE mEXAMPLES PROJECT 
To run the mExamples Project, double-click 
the “mExamples Project” icon, found in the 
“mExamples” folder of your mTropolis instal- 
lation. mTropolis will start and open the 
mExamples Project in edit mode. 


When mTropolis is first started, the program 
is in edit mode. Edit mode is used to author 
projects. Runtime mode is used to preview a 
project. In runtime mode, the project is dis- 
played just as a user would see the completed ti- 
tle. 


¢ Note: Note that there may also be a “mExam- 
ples Title” icon in the mExamples folder. This 
program is the mExamples Project built into a 
standalone title. This title can be run, but can- 
not be edited. 


Running the Project from its First Scene 
Select Run-From Start from the File menu 
(or press #8-T) to switch to runtime and pre- 
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Figure 8.1 The mExample Project’s main menu 


view the project from its first scene (the first 
scene in the first subsection in the first sec- 
tion of the project). The mTropolis interface 
disappears and the project starts. Alternative- 
ly, press #-Option-T to view switch to run- 
time mode but keep the mTropolis interface 
visible. 


Returning to Edit Mode 

Press #6-T again to return to the scene where 
36-T was originally pressed. Alternatively, press 
36-. (Command-period) to return to edit 
mode at the current runtime scene. 


Running the Project from a Selected Scene 
Select Run-From Selection from the File 
menu (or use #-Y) to switch to runtime 
mode and preview the project from the scene 
currently displayed in edit mode. 


To Return to Edit Mode 
Use #-Y again to return to the scene where 


36-Y was originally pressed. Optionally, use 
36-. (Command-period) to stop at the current 
runtime scene. 


THE mEXAMPLES PROJECT INTERFACE 
When run from its first scene, the project 
plays a short movie (which can be bypassed 
by clicking). When the movie finishes, the 
mExample Project’s main menu appears (Fig- 
ure 8.1). There are a number of options avail- 
able in this menu: 


¢ The Basics: Click this option to display a 
menu of simple projects that illustrate 
some basic mTropolis programming con- 
cepts. This section is described in more de- 
tail in “The Basics” on page 8.3. 
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* Modifier Examples: Select this option to 
display a menu of simple projects that illus- 
trate the use of each mTropolis modifier. 


¢ mTutorial: Select this option to run dis- 
play a project similar to that described in 
Chapter 7, “Tutorial”. 


¢ Simple Projects: Select this option to dis- 
play a menu of projects that illustrate more 
advanced mTropolis programming con- 
cepts. These projects are described in more 
detail in “Simple Projects” on page 8.35. 


* Quit Button: Click the blue sphere in the 
lower left corner of the scene to quit the ex- 
amples and return to edit mode. Note that, 
in some scenes, a red sphere is also present. 
Click the red sphere to return to the previ- 
ous menu. 


THE BASICS 


The following options are available in “The 
Basics” submenu: 


¢ Button Gallery: The implementation of 
user interaction through radio buttons, an- 
imated buttons, and buttons with selected/ 
deselected bevels is featured in this project. 


* Calculated Fields: This project demon- 
strates text and graphic “running total” dis- 
plays. 

¢ Changing Cursors: To show the library of 
cursors available in mTropolis’ cursors 
modifiers and how to use them are the 
goals of this project. 
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* Communicating: This project demon- 
strates a simple, but robust use of messag- 
ing. 


* Controlling Audio: This project shows 
how modifiers can be used to control the 
playback of sounds. 


* Controlling mToons: The control 
mToons, mTropolis’ proprietary animation 
format, are featured in this project. 


¢ Linear Navigation: This project shows a 
simple navigational system using arrow 
buttons. 


* Revealing Objects: This project shows 
how to show and hide elements in re- 
sponse to messages. 


* Scene Transitions: This project shows the 
use of mTropolis’ library of transition ef- 
fects. 


* Spatial Navigation: Building a system for 
navigating a 3D world is featured in this 
project. 


COMMON BASICS PROJECTS 
FEATURES 

If you are a relative newcomer to mTropolis 
programming, the following section provides 
a basic description of authoring methods 
used to create a project’s interface screen and 
navigational buttons. These features are com- 
mon to all of the section in “The Basics”. In 
particular, the shared scene, the title bar, and 
the logic of the scene navigational arrows are 
described. 
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Figure 8.2 The shared scene for the Button Gallery 


The Shared Scene 

Shared scenes are special elements that come 
first in a subsection. During runtime, the 
shared scene is visible behind all other scenes 
in a subsection, making it a logical place for 
elements and modifiers that are common to 
them all. For example, the navigational buttons 
that are to appear in all scenes ina section can 
be placed in the shared scene. 


In the Basics Projects, the background image, 
the title bar and the navigational buttons are 
placed in the shared scene. Figure 8.2 shows 
the shared scene for the Button Gallery 
project. 


A background image (bkgd basic gear.pict) is 
linked to the shared scene. This image shows 
through the transparent parts of the buttons, 
which are graphic elements that have been 
laid on top of it. 


The Title Bar 

In projects that have the same title bar over 
multiple scenes, the text element that con- 
tains the title text is placed in the shared 
scene. For example, the title bar text element 
in Figure 8.2 has been placed on the back- 
ground image, the Button Gallery shared scene. 
By applying a graphic modifier with a transpar- 
ent ink effect to the text element, the text’s 
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field is made transparent allowing the back- 
ground image to show through. 


The area of the background image beneath 
the title bar text element in Figure 8.2 has 
been lightened to emphasize the title bar’s 
text. This effect was created in a graphics ap- 
plication before the PICT was linked to the 
project. 


Unlike the background image, the text element 
called “Buttons Text” was not linked to an ex- 
ternal file, but created within the mTropolis 
application with the text tool from the tool 
palette. 


The Navigational Arrow Buttons 

The navigational arrow buttons allow the 
user to move forward or backward in the 
project, from one scene to another. Since they 
are to appear in all project scenes, the buttons 
have also been placed on the shared scene. 


Each navigational arrow button consists of a 
two-celled mToon animation that has been 
linked to a graphic element. The arrow in the 
first cel of the animation is plain, and the ar- 
row in the second cel of the animation is 
dimmed. Miniscript modifiers in the Bevel 
Button behavior on the mToon animation 
control which cel of the animation is displayed 
during runtime, depending on the user’s 
mouse actions. 


Like the title bar text element, a graphic modifier 
configured to apply a Background Transpar- 
ent effect has been placed on the mToon, al- 
lowing the background image to show 
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through. This graphic modifier is inside the 
Bevel Button behavior. 


The figure below shows the three behavior mod- 
ifiers that have been placed on the right arrow 
button. 


Figure 8.3 Arrow mToon with behaviors 


The function of the navigation buttons is de- 
termined by the order and configuration of 
modifiers contained in the three behaviors 
that are placed on them. The contents of each 
of these behaviors are described in the following 
sections. 


Standard Button Behavior 

The Standard Button behavior contains a col- 
lection of messengers that make the button 
work as a proper button should (i.e., clicking 
down on the button highlights it, dragging off 
the button removes the highlight, and releas- 
ing the button will initiate its associated activ- 
ity). This behavior is used on all buttons 
throughout the projects. 


Figure 8.4 shows the modifiers contained in 
the Standard Button behavior (double-click 
on a behavior icon to display that behavior’s 
contents) 


Three author messages are generated at different 
times by the six messengers in this behavior. 
These author messages are “Highlight,” “Un- 
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Figure 8.4 Contents of the Standard Button behavior 


Highlight” and “Execute.” Each of these mes- 
sages is targeted to the modifier’s element, the 
mToon animation. They will automatically be 
broadcast to the modifiers in the other behav- 
iors on the mToon (see “Bevel Button Behav- 
ior” on page 8.7 and ““The Navigational 
Arrow Buttons” on page 8.5 for details.) 


Un-Highlight on Start 

When runtime is first entered, Parent Enabled is 
automatically sent to components through- 
out the project. The first messenger in the 
Standard Button behavior is configured to 
send an “Un-Highlight” author message to 
the mToon button. 


Mouse Down Highlight 
When the user presses the mouse over the 


button, the message Highlight is sent to the 
element. 


Mouse Up Inside Un-Highlight 
When the user releases the mouse over the 


button, the message Mouse Up is sent to the 
element. 


Mouse Up Inside Execute 
When the user releases the mouse over the 


button, an author message called “Execute” is 
also sent. 


Tracked Outside Un-Highlight 

When the user drags the cursor off of the but- 
ton while the mouse is depressed, an “Un- 
Highlight” author message is sent to the ele- 
ment. 


Tracked Inside Highlight 
When the user drags the cursor back onto the 
button while the mouse is depressed, a 
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Figure 8.5 Contents of the Bevel Button behavior 


“Highlight” author message is sent to the ele- 
ment. 


Bevel Button Behavior 

The second behavior on the navigational but- 
tons is called “Bevel Button.” The modifiers in 
this behavior respond to the messages sent 
from the messengers in the Standard Button 
behavior by displaying the correct cel of the 
button animation, and by applying graphic 
beveled edge effects to the mToon navigation 
buttons. Figure 8.5 shows the contents of 
Bevel Button behavior. 


This behavior is also used throughout the 
projects to provide a consistent look to the 
navigation buttons. 


Transparent Ink 

The first modifier applies a background 
transparent ink effect to the animation, which 
allows the background image to show through. 


Pause 
To prevent the mToon button from playing, 
this messenger is configured to send a Pause 
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command on receipt of a Played message. 
This insures that the correct cel is displayed 
on the scene when it is entered. 


Un-Highlight Cel 

On the “Un-Highlight” author message, the 
Miniscript modifier called “Un-Highlight 
Cel” sets the cel of the animation to 1. 


Un-Highlight Bevel 

On the “Un-Highlight” author message, an 
image effect modifier applies a Section 1 bev- 
el effect. 


Highlight Cel 

On the “Highlight” author message, the Mini- 
script modifier called “Highlight Cel” sets the 
cel of the animation to 1. 


Highlight Bevel 

On the “Highlight” author message, an image 
effect modifier applies a highlight bevel ef- 
fect. 
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NAVIGATIONAL BUTTON BEHAVIOR: 
LEFT AND RIGHT 

The third behavior contains the two messen- 
gers used to control the visibility of the right 
and left arrow buttons, and a change scene 
modifier. Figure 8.6 shows the contents of 
the “Left Arrow” behavior. 


By Left Arrow TL Switchable 


Disable when: 


Enable when: 


No Previous Scene 


Play 


Execute | | 


cil (0) 
Hide Element 
+) 


Sto| 
Scene Changed I f 
| 


(2) 


To Previous Scene 


cal (1) 
Show Element 


Figure 8.6 Contents of the Left Arrow behavior 


Hide Element 

When this messenger receives a No Previous 
Scene message, this messenger sends a Stop 
command to its element to hide the arrow 
button. 


Show Element 

When this messenger receives a Scene 
Changed message, it sends a Play command 
to its element to display the arrow button. 


To Previous Scene 
A change scene modifier is configured to 


change to the next or previous scene on re- 
ceipt of the “Execute” author message. 


BUTTON GALLERY 


The “Button Gallery” example, available from 
“The Basics” menu, shows how to create var- 
ious styles of buttons using elements linked 
to PICTs or mToons. Button effects are creat- 
ed using graphic modifiers, or a combination 
of messengers and graphic modifiers. 


The “Button Gallery” project uses various 
mTropolis’ modifiers in combination with its 
messaging system to create of a variety of but- 
ton states, such as selected/deselected. 


This project uses a shared scene, and two other 
scenes called “Button 1,” and “Button 2.” In 
this project, ten button states are shown on 
the two scenes (excluding the navigational but- 
tons that toggle between them). Each type of 
button is described by the text label to its 
right. 


Button Scene 1 


Highlight on Mouse Over 
Effect: The button highlights (flashes) when 


the mouse passes over the button element. 


¢ The image effect modifier named “Button 
Initial State” applies the deselected 3D bev- 
el effect to the button element on receipt of 
a Parent Enabled message. This message is 
sent by mTropolis when the scene is en- 
tered. 


¢ Another image effect modifier named “But- 
ton Highlight” applies a Tone Up effect to 
the Element when it receives a Mouse Over 
message, that is, when the user’s cursor is 
inside the button’s element boundaries. 
The effect is removed (turned off) when a 
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Mouse Outside message is received, that is, 
when the cursor is outside the element’s 
boundaries. 


Highlight on Mouse Down 
Effect: The button highlights when the but- 
ton is selected. 


¢ This button acts the same as the previous 
example, except that the Tone Up effect is 
applied on receipt of a Mouse Down mes- 
sage and removed on receipt of a Mouse Up 
message. 


Select on Mouse Down 
Effect: The button’s beveled edges invert 
when the button is selected. 


¢ The image effect modifier named “Button 
Initial State” applies the deselected bevel 
effect to the button element when the scene 
starts. 


* The image effect modifier called “Button 
Selected” inverts the bevels when the but- 
ton receives a Mouse Down message. 


Select on Enter Key 
Effect: Pressing the Enter key simply inverts 
the beveled edges of the button. 


¢ The keyboard messenger sends an Enter 
Key Pressed message to the button element 
when the Enter key is pressed. 


¢ The image effect modifier named “Button 
Selected” applies a selected bevel to the 
button when the message is received. 


Select/Deselect on Mouse Up/Down 
Effect: Clicking on this button causes the bev- 
eled edges of the button to flash. 


Button Gallery 


* The image effect modifier named “Button 
Initial State” applies the deselected bevel 
effect to the button element on receipt of a 
Parent Enabled message. This effect is re- 
moved on receipt of a Mouse Down mes- 
sage. 


* The image effect modifier named “Button 
Selected” applies a selected bevel effect to 
the button on receipt of a Mouse Down 
message. This effect is removed on receipt 
of a Mouse Up message. 


* The image effect modifier named “Button 
Deselected” resets the button to its initial 
state on a Mouse Up message. 


Button Scene 2 


Show PICT on Mouse Down 
Effect: A lighter PICT of a gear appears over 


the gear graphic when the user clicks on the 
button. The darker gear PICT reappears 
when the mouse is released. 


* The image effect modifier named “Button 
Initial State” applies the deselected bevel 
effect to the button element when the scene 
starts. 


¢ The messenger named “Show Gear Light. pict” 

sends a Play command to the Gear 
Light.pict element when it receives a 
Mouse Down message. 


¢ The messenger named “Hide Gear 
Light.pict” sends a Stop command to the 
Gear Light.pict element when it receives a 


Mouse Up message. 
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Radio Buttons (1 and 2) 
Effect: Clicking on one radio button inverts 


the beveled edge (selected), and causes the 
other radio button to toggle to the opposite 
state (deselected). 


Radio buttons are paired (1 and 2) in this 
project. The method used here can be applied 
to any number of buttons acting as radio but- 
tons. 


* The image effect modifier named “Button 
Initial State” applies the deselected bevel 
effect to the button element when the scene 
starts. The effect is disabled on a Mouse 
Down message. 


¢ The image effect modifier named “Button 
Selected” applies the selected bevel effect 
on a Mouse Down message. This effect is re- 
moved on the “Enable Other Button” au- 
thor message that is sent when the other 
radio button is selected. 


¢ The messenger named “Deselect Radio But- 
ton” sends the “Enable Other Button” au- 
thor message to the other radio button ona 
Mouse Down message. 


* When it receives an “Enable Other Button” 
author message, the image effect modifier 
named “Button Deselected” applies a deselect- 
ed bevel effect to its element. This effect is re- 
moved on receipt of a Mouse Down 
message. 


Toggle Select Behavior Button 

Effect: The button continuously alternates 
between inverted and plain beveled edges, 
creating a blinking button effect. This example 


also demonstrates how a behavior may be 
used as a container for other modifiers, mak- 
ing it easy to copy and transfer programming 
to other elements. 


¢ The messenger modifier named “Button 
Initial State” applies the deselected bevel 
effect to the button element when the scene 
starts by sending a Deselect message to the 
element. 


¢ The timer messenger named “Continuous 
Select/Deselect Toggle” causes the repeated 
flashing of the button. When the scene 
starts, it repeatedly sends a “Toggle Select” au- 
thor message in 0.5 second intervals. The 
Toggle Select message is interpreted by the 
modifiers listening for the author messages 
“Select” or “Deselect.” If the element is cur- 
rently “Select,” it toggles to “Deselect” and 
vice versa. 


* The image effect modifier named “Button 
Selected” applies the selected bevel effect to 
the button element on receiving a Mouse 
Down message. This effect is disabled on 
receipt of a Mouse Up message. 


* The image effect modifier named “Button 
Deselected” applies the selected bevels ef- 
fect to the button element on receiving a 
Mouse Up message. The effect is disabled on 
receipt of a Mouse Down message. 


Animated Button 

Effect: When clicked, the gear image on the 
button continuously rotates. In this example, 
the media linked to the button element is a 
mTropolis mToon animation. 


Button Gallery 
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Figure 8.7 Power Lines.pict and the Object Info palette 


¢ The image effect modifier named “Button 
Initial State” applies the deselected bevel 
effect to the button element when the scene 
starts. 


¢ The messenger named “Play Gear.Toon” 
sends a Play command to Gear.Toon on a 
Mouse Down message. 


¢ In the Gear.toon element, the messenger 
named “Preload Element” sends a Preload 
Media command to its mToon element on re- 
ceipt of the Parent Enabled message. The 
Preload Media command loads the mToon 
animation into memory before the scene 
starts. Animations played from memory, 
rather than from disk, play more quickly 
and more smoothly. 


LINEAR NAVIGATION 

The “Linear Navigation” example, available 
from “The Basics” menu, is a simple slide 
show that illustrates how to change from one 
scene to the next. For information regarding 


Linear Navigation 


navigation through a complex 3D world, see 
“Spatial Navigation” on page 8.12. 


Description 

This project uses the navigational arrows de- 
scribed in “Common Basics Projects Fea- 
tures” on page 8.3. The right and left arrows 
navigate through a series of pictures. When 
there is no “Previous Scene,” the left arrow is 
hidden. When there is no “Next Scene,” the 
right arrow is hidden. 


Adding the Images 
In this project three scenes were created, one 
for each of the PICT elements. 


The pictures linked to the elements were cre- 
ated outside the mTropolis environment. 
They are the same size. After linking the pic- 
tures, the object info palette (Figure 8.7) was 
used to position each PICT element in the 
same location in each scene. 


All three pictures were placed at screen coor- 
dinates 140,112. 
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The navigation buttons allow the user to flip 
through the PICTs linked to each element in 
each scene. 


SPATIAL NAVIGATION 


The “Spatial Navigation” example, available 
from “The Basics” menu, shows how to navi- 
gate through a 3D world. Aliased cursor 
modifiers, transition modifiers and scene 
change modifiers are also discussed. For in- 
formation regarding simple scene-to-scene 
navigation, see the Linear Navigation project 
that immediately precedes this project. 


Description 

The user clicks on a door in the opening 
scene, enters a 3D room, and explores it, 
eventually leaving by the door again. The 
room has twelve different points-of-view, one 
in each lateral direction (four walls), four up 
(ceiling) and four down (floor). Navigating 
up to the ceiling or down to the floor produc- 
es a different view, depending on from which 
wall the user navigates. 


Movement is selectively allowed in right and 
left directions, and up and down directions, 
depending on where the user is located. For 
example, the user can look up to the ceiling 
from any wall, but can only look down to the 
same wall again. To see a different view of the 
ceiling, the user must navigate to a different 
wall. Although navigation is simplified, all 
possible types of movement in a 3D world are 
illustrated. 


¢ Note: Use the structure window (select Struc- 
ture Window from the View menu) to review 


the hierarchical structure of components in this 
project. 


Navigating the Scenes 

Each of the points-of-view in the 3D room is 
a separate scene that has a PICT, such as Ceil- 
ing/Lamp. pict, linked to the background. A 
second, “invisible” graphic element called 
“Down” is placed on the scene. This element 
provides a large hot spot that is configured 
with modifiers to respond to the user’s 
mouse. 


Figure 8.8 shows a PICT of the ceiling that is 
linked to the example scene. The transparent 
element called “Down” contains a cursor, 

scene transition, and scene change modifier. 


¢ Note: The way that scenes in this project are 
navigated is common to all points of view, so 
only one will be discussed. 


The cursor modifier named “Down When 
Mouse Over” changes the default arrow 
pointer to the Hand Down cursor when the 
pointer passes over the area covered by the el- 
ement called “Down.” 


The transition modifier named “Push Up” ap- 
plies a Push transition on a Mouse Up mes- 
sage. This transition will take effect when the 
user clicks on the scene. 


The change scene modifier named “Go To Wall” 
is the last modifier on the Down element. On re- 
ceipt of a Mouse Up message the scene will 
change to Wall/Lamp, the scene specified in 
this modifier (Figure 8.9). 
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Figure 8.8 Layout of the example scene, Ceiling/Lamp 
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Figure 8.9 The “Go to Wall” Scene Transition 
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Aliasing Cursor and Transition Modifiers 
The Spatial Navigation project illustrates the 
use of aliases to maximize authoring produc- 
tivity. An alias is a special copy of a modifier; 
it takes its functionality from the modifier 
from which it was made. In this project, di- 
rectional cursors and scene transitions have 
been aliased and used throughout the scenes. 
Aliasing the modifiers not only prevents hav- 
ing to program each individually, but it also 
saves time if the settings of the modifiers need 
to be changed. For example, all aliased cursor 
modifiers called “Up When Mouse Over” use 
the Hand Up cursor. If the author wanted to 
change this cursor to a pointer, simply chang- 
ing the settings in one alias would update all 
other aliases of the same modifier (Figure 
8.10). 
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Figure 8.10 Alias Palette showing just a few of the 
aliases used in the mExamples project 


The transition modifiers have also been 
aliased, meaning that in order to change the 
rate of all aliased Push Down transition mod- 
ifiers, only the rate settings of one alias would 
have to be changed. 


See “Alias Palette” on page 11.7 of the mTrop- 
olis Reference Guide for details regarding alias- 
es. 


SCENE TRANSITIONS 


The “Scene Transitions” example, available 
from “The Basics” menu, shows how mTrop- 
olis’ scene change modifier is used in combi- 
nation with the scene transition modifier to 
create transitions between scenes. 


Description 

This project contains two scenes. “Transitions 1” 
is the main interface and “Transitions 2” is a 
background image used to demonstrate the 
visual effect of each transition. Clicking on 
one of the gear buttons causes one of a variety 
of transitions to a full screen image. 


Each button in this project is configured the 
same way, except that the settings in the tran- 
sition modifiers vary (i.e., type, direction, 
step and rate settings). The Slide Button tran- 
sition is documented below. 


Slide Button 

The element called “Slide Button” uses the 
Standard Button behavior as well as a behavior 
called “Bevel Button & Next Scene.” (A change 
scene modifier configured to go to the next 
scene on the “Execute” author message has 
been included in the Bevel Button @ Next 
Scene behavior.) 


Each button is configured to function the 
same way, allowing the button behaviors to 
be aliased and used on each. Since the scene 
transition modifiers are used to apply unique 
transition effects, one has been placed on the 
button element beside each aliased behavior. 


The change scene modifier named “Slide 
Transition” on the first button applies the 
scene transition on an “Execute” author mes- 
sage. The Slide Down effect is used, set at 64 
steps and at the maximum rate. 


Double-click on the transition modifier to 
open its dialog. Experiment with different step 
and rate settings for each of the transitions. 


Scene Transitions 
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CONTROLLING mTOONS 

The “Controlling mToons” example, available 
from “The Basics” menu, shows how to use 
modifiers to control mToons, animations cre- 
ated in mTropolis’ proprietary format. 


mTropolis’ mToon animation format creates 
animations composed of individual cels. Un- 
like time-based formats like QuickTime 
which play frames over time, individual cels 
or a range of cels can be named and specified 
for playback. The speed of the animation can 
also be precisely controlled. 


Description 

In this project, the user toggles between two 
scenes. In the first scene, three buttons allow 
the user to play different ranges of cels in the 
scene’s orbiting planet animation. In the sec- 
ond scene, three buttons allow the user to 
play the scene’s orbiting planet animation at 
different speeds. In either scene, the anima- 
tion can be dragged about the scene within 
the constraints of an invisible boundary while 
it continues to play. 


Shei Tip 


Use the structure window to view the modifiers 

and elements in this project. 
Providing Frame-by-Frame Control of mToons 
The animation included with this project 
contains three logical cel ranges. These ranges 
were created in the mToon editor. The first 
scene of the project called “mToon Ranges” il- 
lustrates precise control of the playback of 
these ranges. 
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Messenger modifiers on the buttons are used 
in combination with integer range variables 
on the scene to control the playback of a speci- 
fied range of cels. Depending on which button is 
clicked, a specific range of cels is played. 


Range Variables 

The three integer range variables that define 
the range of cels played by each button are 
placed on the scene. By placing the variables 
on the scene, their values are accessible by all 
modifiers on the elements in the scene (see 
“Variable Scopes” on page 13.25 of the 
mTropolis Reference Guide for details). 


Gear Buttons 

The range of cels the animation will play is 
determined when the user clicks on one of the 
gear buttons. 


Each of the buttons, labeled Slow Button, Me- 
dium Button, and Fast Button, sends an au- 
thor message named “Set Orbit Speed 1,” “Set 
Orbit Speed 2,” or “Set Orbit Speed 3” with an 
integer variable called “Orbit Speed 1,” “Orbit 
Speed 2,” or “Orbit Speed 3” to the scene 
when it is clicked. The variables to which 
each of these messengers refer have been 
placed on the scene. 


A Miniscript modifier can also be used to set 
the range the animation is to play. See Chap- 
ter 14 of the mTropolis Reference Guide, 

“Miniscript Modifier”, for details. 


Radio Buttons 

The Radio Button behavior is used in place of 
the Standard Button behavior. According to 
the programming of this behavior, only one 
button in the group may be active at any one 
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Figure 8.11 Contents of the Radio Button behavior 


time, and this button remains highlighted 
once clicked on. Figure 8.11 shows the con- 
tents of the Radio Button behavior. 


The contents of the Radio Button behavior is 
similar to that of the Standard Button behavior, 
except this behavior contains two additional 
messengers and another behavior. The first 
additional messenger, named “Execute => 
Un-Highlight Other Buttons,” sends an “Un- 
Highlight Other Buttons” author message to the 
element’s parent. This message is then broad- 
cast to all of the buttons in the scene, and to 
their modifiers which are configured to re- 

spond by un-highlighting their elements. The 


next additional messenger, called “Execute => 
Highlight,” sends the opposite message to the 
scene, causing the buttons in the scene to 
highlight. 


The additional behavior (Figure 8.12) contains 
two messengers that highlight and un-highlight 
the button when the mouse is tracked inside 
and outside the boundaries of the button ele- 
ment. These actions are switched off on re- 
ceipt of the “Execute” author message so that 
when the button is pressed down, tracking 
over it again won't un-highlight it. 


Animation Modifiers 

The orbit mToon on the mToon Ranges scene 
contains a behavior and two messengers. 
Since the functionality of the behavior is also 
required in the next scene, mToon Speed, the 
behavior has been aliased. 


The alias “Demo mToon” behavior contains 
the following modifiers: 
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=== Sampler Project 4: Switched Actions === 
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Figure 8.12 Contents of the Switched Actions 
behavior 


¢ A graphic modifier that applies a transparent 
background ink effect. 


¢ Adrag motion modifier that allows the user 
to drag the animation around the screen with- 
in a limited area. To define the boundaries 
within which the animation can be 
dragged, the animation is made a child of 
an invisible element with the parent/child 
tool. The drag motion modifier on the ani- 
mation is then configured to confine the 
user’s dragging of the element to the 
boundaries of its parent. For more about 
parent/child relationships, see “Effects of 
Parent/Child Relationships” on page 8.7 of 
the mTropolis Reference Guide). 


¢ A behavior that contains three cursor mod- 
ifiers used to simulate a hand picking up 
the animation. These modifiers are activat- 
ed on Mouse Over, Mouse Down and 
Mouse Up messages respectively. 


¢ Two Miniscript modifiers that reset the po- 
sition of the animation on Scene Started 
and Scene Ended messages. By using these 
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Miniscripts, if the user moves the element 
during runtime, its position will be reset 
when the scene ends. 


Changing the Range of Animations 

The messenger on the first button, called “Set 
Orbit Range 1,” acts on receipt of the Execute 
message. It sends “Set Orbit Range” with the 
variable “Orbit Range 1” to the scene. The 
Miniscript on the Orbit.toon animation, 
called “Set Range,” responds to this message 
by setting the range of the Orbit.toon anima- 
tion to the value of the incoming integer range 
variable. 


The messenger on the Orbit.toon animation, 
called “Play Animation,” is also activated ona 
“Set Orbit Range” author message. Upon re- 
ceipt of this message, it sends a Play com- 

mand to the mToon, causing the animation to 


play. 


Except for the value of the variables that they 
send, the programming of each of the buttons is 
the same. 


¢ Note: Try duplicating the animation object 
(Edit menu—Duplicate, or 6-D), then run the 
project. Now drag the animation elements 
away from each other, and click one of the but- 
tons. 


¢ The “Demo mToon” behavior has been 
aliased, because it is used in the next scene, 
called “mToon Speed,” as well. 


Changing the Rate of Animations 

The scene called “mToon Rate” functions 
similarly to the mToon Ranges scene, except 
that the messengers on the three gear buttons 
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set the speed of the animation rather than the 
range of cels to play. The variables to which 
they refer have been placed on the scene. 


The Orbit.toon animation has been configured 
to play Range 2, cels 10-19 at various speeds 
when one of the three buttons is pressed. 


The Gear Buttons 
The speed of the animation is set when the 
user clicks on one of the gear buttons. 


Each of the buttons, labeled Slow Button, Me- 
dium Button, and Fast Button, sends an au- 
thor message named “Set Orbit Speed 1,” “Set 
Orbit Speed 2,” or “Set Orbit Speed 3” with a 
integer variable called “Orbit Rate 1,” “Orbit Rate 
2,” or “Orbit Rate 3” to the scene when it is 
clicked. The variables to which each of these 
messengers refer have been placed on the scene. 


¢ Note: A Miniscript modifier could also be used 
to set the animation’s speed. See Chapter 14 of 
the mTropolis Reference Guide, “Miniscript 
Modifier”, for details. 


The Animation 
The mToon on this scene has an aliased be- 
havior, two messengers and one Miniscript. 


For details regarding the functioning of the 
alias “Demo mToon” behavior, see its docu- 
mentation earlier in this section entitled “An- 
imation Modifiers.” 


The first messenger called “Set Default Range” 
sets the range of the animation with the integer 
variable named “Orbit Range 2” that is located 
on the scene. 


On receipt of the author message “Set Orbit 

Speed,” the Miniscript modifier named “Set 

Speed” sets the rate of the mToon to the value 
of the incoming integer variable. 


The second messenger, called “Play Animation,” 
sends a Play command on receipt of the “Set 
Orbit Speed” author message. 


COMMUNICATING 

The “Communicating” example, available 
from “The Basics” menu, shows how to use 
mTropolis’ messaging system to switch the 
states of objects in a lighting system. Also fea- 
tured is the use of aliased behaviors to associ- 
ate identical copies of the behavior with 
various elements. Finally, this project also 
shows how to control mToons (mTropolis’ 
proprietary animation format) with modifi- 
ers, especially ‘if and Miniscript modifiers. 


Description 

In this project, a small lighting system is 
modeled, comprised of a main power switch, 
indicator lights, and two light bulbs with 
their own power switches (Figure 8.13). 


When the main power switch is on, it supplies 
electricity to the light bulb switches. Indica- 
tor lights on the light switch plates turn green 
to show power has reached the light switches. 
Clicking on the light bulb switches turns the 
light bulbs on and off. The bulbs can be 
dragged from their sockets by the user. If they 
are lit, removing them from the socket causes 
them to go out. The bulbs are also inter- 
changeable between the two sockets. 


Communicating 


mTropolis Developer Guide 8.19 


Figure 8.13 The Communicating example lighting system 


Since both bulbs behave in the same way, the 
behaviors on the light bulbs have been aliased. 


How the Lighting System is Programmed 
The project uses mToons, mTropolis’ propri- 
etary animation format, to represent the on/ 
off states of switches and lights. mToons were 
chosen because the display of the cels of the 
animation can be controlled by modifiers. Be- 
cause the basic states of switches are up or 
down, and lights are on or off, all mToons 
consist of two cels. For example, if the main 
switch is off, the cel showing the switch in its 
down position is displayed. If the switch is 
on, the cel displaying the switch in its up po- 
sition is displayed. 
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The messaging system uses a combination of 
‘if, Miniscript, and variable modifiers to man- 
age the state of the system. The authoring is 
designed to implement the following logical 
construction: 


¢ If the main power switch is on, and 


if the light bulb switch is on, and 


if the light bulb is in the socket, 
* then display the light bulb in its on state. 


The on/off states of switches are stored in 
Boolean variables placed on the scene. This 
position makes them accessible to all elements 
in the scene. 
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¢ Note: See “Variable Scopes” on page 13.25 of 
the mTropolis Reference Guide for details re- 
garding the placement of variables. 


Collision messengers are used to determine if 
the bulb is in the socket. These reside on an 
“empty” graphic element locked into position 
over the bulb stem. 


Author messages are used to signal other ele- 
ments as to the presence of the bulb in the 
socket and the power state of switches. For 
example, the Socket Mask that hides the bulb 
stem receives author messages. 


Since the light bulbs use the same logic to de- 
termine if they are on (lit) or off (unlit), an 
alias of the “Bulb Behavior” is used. 


User interaction with the switches and bulbs 
are handled by modifiers residing on the re- 
spective elements. For example, modifiers on 
the main power switch are configured to re- 
spond to a mouse click and to notify other 
modifiers to initiate new actions. 


Each of the parts of the lighting system will be 
described in turn. 


The Scene 
The scene component contains the background 
image. 


The three Boolean variables on the scene 
store the current state of the switches, and, 
therefore, the flow of electricity through the 
system. These are checked by modifiers at- 
tached to the elements in the scene. The vari- 
ables are as follows: 


* switchAon: the light switch for the left 
light bulb 


* switchBon: the light switch for the right 
light bulb 


¢ thePowerlsOn: the state of the main pow- 
er switch 


When the scene starts, the Miniscript modifier 
named “Reset variables” sets the variables to 
“false” (“off”). The lighting system is off. 


Main Power Switch 
The element called “Main Power Switch” turns 
power on and off for the entire lighting system. 


The Miniscript modifier named “Set Handle 
Position and Power” on the main switch ele- 
ment controls the state of the power and the 
position of the power handle. It tells the 
switch animation which frame to play and 
sets the value of the Boolean variables on the 
scene. The Miniscript also sends an author 
message “PowerON” or “PowerOFF” to the 
scene to notify all elements of the state of the 
power supply. Since author messages are 
broadcast from the scene to its elements and 
modifiers, the modifiers are automatically no- 
tified when the user has turned the main 
power on or off. 


Indicator Lights 
The indicator lights respond to PowerON and 


PowerOFF messages sent by the main power 
switch. 


The Indicator Light elements contain an 

aliased “SwitchLight” behavior. Two Miniscript 
modifiers encapsulated in the “SwitchLight” 
behavior listen for the on/off messages from 
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the main power switch. When they receive a 
“PowerON” author message they play the cel 
that shows a green light in the Indicator anima- 
tion. A “PowerOFF” author message plays the 
other cel (the black light). 


Light Bulb Switches 

The light bulb switches (Switch A and Switch B) 
control the flow of electricity to the light bulb 
from the main power supply. 


Each switch element contains a Miniscript 
modifier called “Toggle Switch State” that 
toggles the switch animation between the up 
and down frames. It also toggles the switchA- 
on or switchBon variables on the scene be- 
tween true or false. That is, if the light bulb 
switch is currently on, and the user clicks on 
the switch, the modifier sets the respective vari- 
able to false, and vice versa. 


Power Source A and Power Source B Elements 
Empty graphic elements called “Power Source 
A” and “Power Source B” are located within 
the boundaries of the light bulb sockets. They 
contain the most important modifiers for im- 
plementing the logic between the bulbs and 
the power sources. Specifically, they turn the 
associated light bulb on by sending a “Turn 
On” author message to the light bulb ele- 
ment. Their associated behaviors are similar, al- 
though their state depends upon the state of 
the associated power switch and the state of 
the main power switch. 


Each Power Source element behavior encap- 
sulates three other behaviors. These divide 
programming into three logical sections: User 
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Drags Bulb, Power Up Checks, and Power 
Down Checks. 


¢ The behavior called “User Drags Bulb” simply 
turns the bulb on and off as it is dragged 
over the light bulb socket. It encapsulates 
two modifiers, one that sends a “Turn ON” 
author message to the bulb if the power is 
on to the socket and the light bulb switch 
is on, and one that sends a “Turn OFF” au- 
thor message to the bulb if the bulb is out 
of the socket. 


¢ The behavior called “Power Up Checks” 

uses collision detection to test for the exist- 
ence of a bulb in the socket when the main 
power is turned on, or alternately when the 
light bulb switch is turned on. The two ‘if 
modifiers contained within this behavior 
decide whether to test for a bulb in the first 
place. 


The first ‘if modifier, named “Check for 
bulb on PowerON,” is executed upon re- 
ceipt of a “PowerON” author message, that 
is sent from the main power switch. Then 
the modifier checks if the appropriate pow- 
er switch is on by checking the state of the as- 
sociated variable (e.g., SwitchAon). If the 
variable is true, then a check is made for a 
light bulb with a collision modifier named 
“Check for a bulb over me (ON).” If this is 
true, the “Turn ON” author message is sent 
to the message sender (the light bulb). 


The second ‘if modifier is named “Check 
for bulb on Switch A ON,” and executes its 
test upon receiving the “Switch A ON” au- 
thor message from the power switch. It 
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checks the value of the variable called “theP- 
owerlsOn.” If this value is true, then a check 
is made for a light bulb with the collision 
modifier named “Check for a bulb over me 
(ON).” If this is true, the “Turn ON” author 
message is sent to the message sender (the 
light bulb). 


The collision modifier in this behavior 
named “Check for a bulb over me (ON)” 
tests for a light bulb over the Power Source 
element when it is sent a “Check for a bulb 
(ON)” author message from either of the 
above ‘if modifiers. Notice that the modifi- 
er enables and disables itself on the same 
message. This implements a quick collision 
test. The “Which bulb is here? (ON)” au- 
thor message is sent once to all elements 
colliding with the Power Source element at 
the instant the “Check for a bulb (ON)” au- 
thor message is received. 


Ifa light bulb was detected, the “Which 
bulb is here? (ON)” author message is sent 
to the light bulb (the message sender). If 
the bulb is detected, it responds by sending 
back the author message “A bulb is here 
(ON).” Upon receipt of this message, the 
last messenger in this behavior sends back 
to the light bulb a “Turn ON” author mes- 
sage. 


* The behavior called “Power down checks” 
looks for a bulb over a power source. Ifa bulb 
is present, it turns it off when the associated 
power switch turns off. 


On receipt of a “Switch A OFF” author 
message, the first messenger named 


“Check for bulb on Switch A OFF” sends a 
“Check for a bulb (OFF)” author message 
to itself. 


The collision messenger named “Check for 
a bulb over me (OFF)” functions the same 
as in the above behavior. 


The final messenger in this behavior sends 
a “Turn OFF” author message to the sender 
of the “A bulb is here (OFF)” author mes- 
sage. 


Light Bulbs 

The Light Bulb elements are programmed 
identically, that is they use an aliased behav- 
ior called “Bulb Behavior.” Inside the behav- 
ior lies a graphic modifier named 
“Transparent Black” that makes the back- 
ground of the bulb transparent, and a drag 
motion modifier named “Drag” to enable 
dragging of the bulb. The last item in the be- 
havior is a messenger that sends the author 
message “Turn OFF” to the Miniscript on the 
bulb. Two Miniscript modifiers set the cel of 
the bulb animation to 1 or 2 on the “Turn OFF” 
or “Turn ON” author message respectively. 
There is also a behavior within the “Bulb Be- 
havior” called “Cursors.” It contains three 
cursors that change the Hand cursor to a 
Hand Clenched cursor. 


The bulb elements each have a small child el- 
ement named “Bulb Stem.” 


Bulb Stems 

The presence of the light bulb in the light 
bulb socket is tested by a small empty graphic 
element named “Bulb Stem.” It is attached to 
the light bulb as a child element. 
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Figure 8.14 The Socket Mask effect 


To study the “Bulb Stem” behavior, open the 
structure window. Then click on the expand 
triangle beside one of the Light Bulbs. Select 
the Bulb Stem element. Then open the layout 
window to see the Bulb Stem element high- 
lighted with a thick dotted line. 


The purpose of the Bulb Stem elements is to 
limit the collision region of the bulb. If the 
entire bulb were an active collision region, 
touching a power source with the glass part of 
the bulb would turn on the bulb! 


Notice that the Bulb elements used an aliased 
behavior (“Bulb Stem” behavior). This allows 
the developer to apply the programming of 
one bulb to the other. 


The two collision modifiers within the Bulb 
Stem behavior send the author messages 
“Bulb is here” and “Bulb is gone” to all objects 
colliding or “uncolliding” respectively with 
the bulb stem. 


The messengers named “Bounce ‘Turn ON’ to 
parent” and “Bounce ‘Turn OFF’ to parent” 
simply tell the light bulb to turn itself on or 
off when the stem gets these messages. These 


Communicating 


modifiers are used in the conversation between 
the bulb stem and a power source. 


The other pair of modifiers, named “Bounce 
back answer (ON)” and “Bounce back answer 
(OFF),” send a message back to the message 
sender (a Power Source element) that says a 
bulb is here. 


Sockets and Socket Masks 

Socket A and Socket B are empty elements 
containing messengers that send messages to 
their respective Socket Masks. 


The Socket Mask is used to hide the bulb’s 
stem when it is placed inside the socket (Fig- 
ure 8.14). 


The mask, which is shown dark in the figure, 
is invisible to the user. 


Upon receipt of a “Bulb is here” author message, 
the Socket sends a Play command to its respec- 
tive, initially hidden, Socket Mask element. 
The Socket Mask element then appears over 
the light bulb stem and the background. This 
is because it has a higher draw order number 
than both the background it is placed over, and 
the bulbs. 
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When the Socket receives a “Bulb is gone” au- 
thor message, a Stop command is sent to the 
Socket Mask element, making it disappear 
from view. 


The Bulb is here and “Bulb is gone” author 
messages are sent by collision modifiers on 
the Light Bulbs. 


CHANGING CURSORS 


The “Changing Cursors” example, available 
from “The Basics” menu, shows how to use 
mTropolis’ cursor modifier to dynamically 
change the cursor icon as it passes over selected 
elements. 


Description 

mTropolis uses a system pointer as its default 
cursor. It also uses a Hand Pointing Up when 
the mouse is over an element that has been 
configured with a modifier to respond to a 
mouse message. However, several other types 
of mouse cursors are stored by the cursor 
modifier. Figure 8.15 shows the list of cur- 
sors available on the pop-up menu in the cur- 
sor modifier. 


The first four examples in the project show 
four of these cursors (Hand Up, Hand Right, 
Hand Left, Hand Down). In each case, the 
cursor is changed to the one selected in the 
cursor modifier pop-up when the mouse cur- 
sor passes over the gear button element. 


The fifth example, named “Draggable Ob- 
ject,” uses multiple modifiers to change the 
cursor and make the gear element draggable. 


Cursor Modifier 


ue Cursor 


Apply when: Default inacti int 

efault inactive pointer 
Default active pointer 
; — Specifications B&W hand clenched 


B&W hand outstretched 


Hand right 
Hand left 
Hand down 
Hand clenched 


Hand outstretched 
System arrow 
Pencil 

Happy face 

Watch 

None 


Figure 8.15 Cursors available in the cursor 
modifier 


Draggable Object 

The fifth gear element can be dragged and 
dropped during runtime within the boundaries 
of the scene. 


At scene start, a drag modifier named “Allow 
Dragging” sends a message to the element to 
allow dragging. The cursor modifier, named 
“Cursor Initial State,” changes the cursor to 
the Hand Outstretched on a Mouse Over 
message. 


The cursor modifier named “Clenched Cursor” 
changes the cursor to the Hand Clenched on 
a Mouse Down message. 


The cursor modifier named “Outstretched 
Cursor” changes the cursor to the Hand Out- 
stretched on a Mouse Up message. 


The Miniscript modifier named “Reset Element 
Position” resets the element to its initial position 
when the scene ends. 
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REVEALING OBJECTS 


The “Revealing Objects” example, available 
from “The Basics” menu, shows how to dis- 
play images from another scene, the current 
scene, or a shared scene. 


Description 

In this example, clicking on buttons in the 
scenes allow the user to see the current image 
in another scene; hidden images in the current 
scene, or, images from other scenes in the 
current scene. 


The following section outlines the methods 
used to program messengers and change 
scene modifiers to: 


* Show images from another scene. 
* Show hidden images in a current scene. 
* Show images from the shared scene. 


Button Behavior 
The gear button uses two behaviors: Bevel 


Button behavior and the Radio Button behav- 
ior. The first behavior provides typical high- 
light and un-highlight button behavior, and 
the second behavior makes the button con- 
tinue to appear depressed while the image is 
displayed on the scene. 


Showing Images from Another Scene 

The gear button in the first scene contains a 
change scene modifier that is configured to 
show the current scene under another speci- 
fied scene when the user clicks on it. 


When the user clicks on the button and the 
change scene occurs, the element called “Lay- 


Revealing Objects 


ered Image” appears over the scene called 
“Show Image From Another Scene.” That is, 
the first scene is layered under the new scene. 


Layered Image Scene 

The scene called “Layered Image” contains 
two transition modifiers. One applies a ran- 
dom dissolve effect on receipt of the “Scene 
Started” message, the other applies the same 
effect on the “Scene Ended” message. As a re- 
sult, when the user clicks on the button, the 
image appears to dissolve into and out of the 
background image. 


The user may only change scenes from this 
scene by clicking on the image. This is ac- 
complished by layering the elements in this 
scene to confine the active area of the screen. 


In order to disable invalid user choices, that 
is, the navigation buttons at the bottom right 
of the scene and the top left of the scene, a 
transparent element called “Disable User Ac- 
tions Button” has been placed over the scene, 
but under the element called “Smoke- 
stacks. pict.” 


¢ Note: A messenger called “Absorb Mouse Mes- 
sages” configured to receive (and absorb) the 
mouse messages generated by user’s mouse 
clicks has been placed on the invisible element 
in the scene. This keeps any additional modifi- 
ers on other elements from inadvertently being 
triggered when the user clicks on the screen. 


To view the layer order of these two elements, 
switch to the layout window. The elements 
are visible at positions 7 & 8. 
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The layered element called “Smoke Stack” is 
also modified with a return modifier that is 
activated on a “Mouse Up” message. Clicking 
on the smoke stack image returns the user to 
the first scene. 


There is one disadvantage to layering scenes 
and that is slightly slower performance, since 
more than one scene needs to be “processed.” 


Showing a Hidden Image on a Scene 

The next example uses simple messaging to 
show and hide an image called “Man In 
Rain.pict.” This method is used for images to 
be shown on a single scene, called “Show 
from Scene.” 


Gear Button 

Both the Standard Button and the Bevel But- 
ton behaviors are used to create the function- 
ality of this button. (See “Common Basics 
Projects Features” earlier in this section for 
information on the use of button behaviors.) 
A single messenger, called “Show Scene Im- 
age,” also is placed on the element. On receipt 
of the author message “Execute,” this messen- 
ger sends a Play command to the Man in 
Rain.pict, causing the image to appear on the 
scene. 


The Man in Rain 

Two messengers have been placed on The 
Man in Rain.pict element. The first, called 
“Hide on Mouse Up,” sends a Stop command to 
its element on a receipt of a “Mouse Up” au- 
thor message. On receipt of the message 
“Stop-Hidden,” the second messenger on the 
PICT, called “Un-Highlight Button,” sends 
the author message “Un-Highlight” to the 


scene. This message activates the program- 
ming of the Bevel Button behavior, causing it 
to un-highlight the gear button. 


Showing Images in a Shared Scene 

The next example shows an image from the 
shared scene. During runtime the shared 
scene appears behind all other scenes in a 
subsection. 


The Gear Button contains a messenger called 
Show Shared Scene Image. When the user 
clicks on the gear button, this messenger 
sends the message “Show Shared Scene Im- 
age” to the shared scene. 


The element named Power Lines.pict in the 
shared scene has four messengers: 


¢ The messenger called “Hide on Scene 
Changed” sends a Stop command to the ele- 
ment on receipt of a “Scene Changed” au- 
thor message. This causes the image to 
disappear when a scene change occurs (i.e., 
when the user clicks on the button). 


¢ The messenger called “Show Element” 
sends a Play command to the element on 
receipt of the “Show Shared Scene Image” 
author message. 


¢ The messenger called “Hide on Mouse Up” 
sends a Stop command to the element on a 
receipt of a “Mouse Up” author message. 


* On receipt of the message Stop Hidden, the 
messenger called “Un-Highlight Button” 
sends the author message “Un-Highlight” 
to the active scene. This message activates 
the programming of the Bevel Button be- 
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Figure 8.16 The Calculated Fields example 


havior, causing it to un-highlight the gear 
button. 


CALCULATED FIELDS 

The “Calculated Fields” example, available 
from “The Basics” menu, shows the methods 
for displaying variable data in text elements, 
such as the display of the current system date, 
or counters that display values dynamically. 


Description 

The Calculated Fields project shows how to 
display values in text elements using a variable 
or a reserved word. The current value of the 
variable or reserved word is substituted at 
runtime. 


Calculated Fields 


The first five examples in this project use the 
reserved words: “time,” “long time,” “date,” 
“long date,” and “abbrev date.” These are re- 
placed with the computer’s current date and 
time at runtime. 


The last example uses a counter that changes 
interactively during runtime as the user drags 
ona slider. 


Showing the Date and Time 

Figure 8.16 shows the buttons, display box- 
es, and date and time text displays in the 
scene. 


The five date and time displays have the fol- 
lowing in common: 
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* The buttons along the left side of the screen 
are created using the methods described in 
“Common Basics Projects Features” earlier 
in this section. 


* Between the buttons and the display boxes 
are text labels. These are standard text ele- 
ments containing graphic modifiers. 


* The Date and Time display boxes are created 
with graphic elements and image effect 
modifiers. The modifiers are configured to 
give the display box an inverted beveled 
edge. 


¢ A text element is added on top of the dis- 
play box. The text element contains the re- 
served word that is updated at runtime. It 
is hidden when the scene starts. 


¢ When the user clicks on a button, a mes- 
senger sends a Play command to the text el- 
ement on the display box. 


¢ A messenger on the text element is config- 
ured to respond to the Play command by 
updating the reserved word. The current 
date or time is then displayed. 


The displays are created using similar meth- 
ods, with the following exceptions and notes. 


Regular Time Display 

The timer modifier named “Update Text Pa- 
rameters” starts a looping timer on the Played 
message. On each iteration of the loop, the 
modifier sends an Update Calculated Fields com- 
mand to the element. This updates the time 
value in the text field. 


Long Time Display 

The Long Time display is configured the 
same as Regular Time, but appends seconds 
to the display as well. 


Regular Date Display 

The Regular Date contains the system’s current 
Short Date, as defined in the system’s Date & 
Time control panel (e.g., 12/24/95). 


Long Date Display 
This field contains the long version of the sys- 
tem date (e.g., December 24, 1995). 


Abbreviated Date Display 
This field shows yet another view of the sys- 
tem date (e.g., Dec. 24, 1995). 


Showing a Graphical Counter 

The Calculated Fields example includes a 
graphical counter (labeled “Counter”) and its 
accompanying slider (Figure 8.16). 


How the Counter Works 

The user slides a knob along a slider, chang- 
ing the value in a display box. Moving the 
slider to the right changes the value in one unit 
increments from 0 to 9 (ten units). Sliding the 
knob to the left reduces the display in one 
unit decrements. 


The Parts of the Counter 
The counter has the following parts: 


¢ The label “Counter” is a standard text ele- 
ment called “Counter Text.” 


¢ The slider is an element called “Counter 
Slider” linked to an image of a slider. 


¢ The knob is an element called “Knob.pict” 
linked to an image of a knob. 
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¢ The counter display box is created in the 
same way as the display boxes in the date 
and time examples. It is an “empty” ele- 
ment to which an image effect modifier has 
been added. The modifier creates bevels 
along the boundaries of the element. 


¢ A text element in the display box contains 
a word surrounded by angle brackets: 
<numHolders. The angle brackets prompt 
mTropolis to look for an Integer variable, 
called “numHolder.” 


How the Counter was Programmed 

As the knob is moved from one position 
along the slider to the next, its current 
“counter value” is calculated and sent to the 
counter display. Most of the functionality of 
the graphic counter resides in modifiers on 
the knob element. The knob element is a 
child element of the Counter Slider element. 


Finding the Width of the Slider 

The width of the Counter Slider element is 
calculated at runtime by a Miniscript modifi- 
er named “Store width of parent” (the slider is 
the parent). The current width of the slider is 
stored in a variable called “pWidth.” 


Dividing the Width into Counter Units 

The width of the slider is divided into ten 
units displayed by the counter. For example, 
if the slider is 200 pixels wide, then a move- 
ment of 20 pixels changes the count by 1. 


A value of 0 represents the leftmost extent of 
the Slider element and is stored in a variable 
named “sliderMin.” A value of 9 represents 
the rightmost extent of the element and is 
stored in a variable named “sliderMax.” 
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Since the counter values are relative to the width 
of the slider element (it’s divided into units of 
ten), changing the width of the slider element 
does not affect the range of values displayed. 


The values given to the sliderMin and slider- 
Max variables can be changed in edit mode, 
allowing the author to change the relative 
range displayed by the counter. For example, 
changing sliderMax to 100 creates a counter 
that tracks the movement of the knob in units 
of 1 between 0 and 100. 


Moving the Knob 

The knob has a drag motion modifier named 
“Drag Horizontal Only” that has been set to con- 
strain the movement of the knob to the 


boundaries of the parent Counter Slider. 


Calculating the Knob's Relative Position on the 
Slider 


When the user moves the knob, its messenger 
called “Update Slider on Mouse Tracking” 
sends the author message “Update Slider Val- 
ue” to the knob element. 


A Miniscript modifier, called “Calculate 
(sliderValue)” listens for this message and cal- 
culates the knob’s current screen position rel- 
ative to the Slider (Figure 8.17). 


This figure is converted into a value between 
0 and 9. The value is stored in the “sliderVal- 
ue” Integer variable. 


Updating the Counter Display 

A messenger on the knob called “Update 
Number Field” hears the same “Update Slider 
Value” author message as the Miniscript. It 
sends a “New Number” author message along 
with the new value for sliderValue to the scene. 
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Miniscript Modifier 


Execute When: 


Update Stider Value | [+] 

Script 
-- This script calculates a value no smaller than 
-- [sliderMin] and no greater than [sliderMax]. It uses 
I-- the width of the parent element and the width of the 
-- knob to average out integer values between the 
I-- range stated above. 


set sliderValue to abs((sliderMaxtsliderMin)-\ 
(((pwidth-width)-position.x)*% 
I((sliderMax-sliderMin) /(pwidth-width))+sliderMin)) 


Figure 8.17 The Calculate [sliderValue] Miniscript 
modifier 


A messenger named “Update Text Parame- 
ters” on the display box hears the “New Num- 
ber” author message and sends an Update 
Calculated Fields command to the Counter 
Text element. 


The Miniscript called “Update Number” on 
the Counter Text element also acts on the 
“Update Number” author message by updating 
the numHolder Integer variable. This causes 
the text element to display the new Counter 
Display value. 


CONTROLLING AUDIO 


The “Controlling Audio” example, available 
from “The Basics” menu, shows how mTrop- 
olis’ sound effect modifier and sound fade 
modifier can be used to control the playback 
of sounds. 


Description 

This project uses a shared scene and two oth- 
er scenes called “Controlling Audio 1” and 
“Controlling Audio 2.” 


The first scene illustrates different uses of 
both sound elements and the sound effect 
modifier. It contains a single button on the 
left, and three sets of buttons on the right. 


Two sound effect modifiers have been placed 
on the single button, a graphic element. 
When this button is clicked upon, its sound 
effect modifiers are activated, causing two on/ 
off aiff sounds linked to them to play. 


Each pair of buttons controls the on/off states 
of three sound elements called “Water.aiff,” 
“Frogs.aiff,” and “Birds.aiff.” By clicking on 
the buttons, each of the aiff files linked to the 
sound elements can be played or stopped, or 
they can be played or stopped while the other 
sounds play. 


The second scene illustrates the program- 
ming of four more buttons used to control a 
single sound element. Clicking on one of 
each pair of buttons fades the sound in or out, 
or increases or decreases its volume. 


Linking Sounds to a Project 

In the mTropolis environment, sounds can be 
linked to a project in two ways. Individual 
sound files can be linked directly to sound el- 
ements, or indirectly to other elements via 
sound effect modifiers. As sound elements 
have no graphic component, they cannot be 
created in the layout window. 
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To create a sound element, switch to the 
structure window. Select an element and 
choose New Sound from the Object menu. 
The new sound element, represented by a 
speaker icon, will appear in the selected loca- 
tion. Snd or aiff sound files may now be 


linked to the selected element by choosing 
the Link Media option from the File menu. 


To link sound files using the sound effect 
modifier, drag this modifier from modifier 
palette group 2 to any element, in any view. 
Double-click its icon to open its dialog. Select 
Link File from its Sound pop-up menu. Se- 
lect a snd or aiff file from the navigation dia- 
log that appears. 


Controlling Audio 1 

Two sound effect modifiers were placed on 
the left button, an mToon graphic element. 
Individual sound files were then linked to 
these sound effect modifiers. Each modifier 
was then configured to respond to author 
messages generated by the Standard Button 
behavior in response to the user’s mouse ac- 
tions. 


Each on/off button element in the scene is 
also an mToon graphic element. For each pair 
of buttons, a sound element was created as its 
sibling in the structure window. Each sound 
element was then linked to a sound file: Wa- 
ter.aiff, Frogs.aiff, and Birds.aiff. 


Instead of the Standard Button behavior, Ra- 
dio Button behaviors have been used to 
switch one button on when the other is off. 
As this behavior’s programming requires each 
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pair of buttons share the same parent, they 
have been made children of the text element 
that describes them. This allows author mes- 
sages generated by the Radio Button behavior 
that are targeted to a parent (in this case, the 
text element) to be simultaneously received 
by all child elements and their modifiers (in 
this case, the on/off button elements, the 
sound element, and all their modifiers). 


With the exception of messengers that send 

Play or Stop commands to each sound element, 
the programming of all “off” buttons and all 

“on” buttons is the same, allowing aliases to 

be used on each. 


Single Sound Button 

Like the navigation buttons documented in 
“Common Basics Projects Features” on 

page 8.3, the Single Sound button is a two- 
celled mToon animation that uses the program- 
ming of the Standard Button behavior and the 
Bevel Button behavior. 


These behaviors control the display of the 
highlighted or un-highlighted cel of the gear 
mToon animation, and they function to apply 
highlighted and un-highlighted effects to the 
button element’s beveled edges. They also 
send out messages in response to the user’s 
mouse actions, and these are used to activate 
the element’s two sound effect modifiers. 
These modifiers are described below. 


Click In on Highlight 

The Highlight message generated in response 
to a mouse down on the button activates the 
sound effect modifier called “Click In on 
Highlight.” 
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Click Out on Execute 
The Execute message generated in response 


to a mouse up on the button activates the 
sound effect modifier called “Click Out on 
Execute.” 


The Water, Bird and Frog on/off buttons in 
Scene | are all programmed alike. The pro- 
gramming of the first set of buttons is docu- 
mented below: 


Water Off Button 
The Water Off button is a two-celled mToon 


element configured with two behaviors and 
three messengers. 


The aliased messengers used to send Execute 
and Highlight messages activate the modifiers 
in the Radio Button and Bevel Button behav- 
iors when the scene starts. These behaviors 
function together to show the highlighted cel 
of the mToon animation, and to simulta- 
neously apply the highlight bevel effects to 
the button’s beveled edges. When the user 
clicks on the Water On button, modifiers in 
the Radio Button behavior are again activated, 
causing the On/Off buttons to switch states. 


The messenger called “Stop Sound Execute” 
is used to control the sound file. The author 
message “Execute” is generated when the 
scene starts and again when the user clicks on 
the button. This triggers the messenger which 
sends a Stop command to the Water.aiff. 


Water On Button 

The Water On button is also a two-celled 
mToon element. With the following excep- 
tions, the programming of the Water On and 
Water Off buttons is the same. 


¢ The messengers “Highlight on Start” and 
“Execute on Start” are not used on the Water 
On button. This is because the Water On but- 
ton does not appear selected when the scene 
starts. 


¢ The messenger “Stop Sound Execute” is re- 
placed by the messenger called “Play Water 
Sound.” This messenger sends a Play command 
to the “Water.aiff when the user clicks on the 
button. 


Controlling Audio 2 

In this scene, four buttons called “Fade In,” 
“Fade Out,” “Volume Increase” and “Volume 
Decrease” are used to control a single sound 
element. 


Fade In/Fade Out Buttons 

Since the first pair of buttons are radio buttons 
that may be on or off, they are configured 
with the Radio Button behavior as well as the 
Bevel Button behavior. The programming of 
the Radio Button behavior used to switch the 
button’s states is designed to send messages 
to the button’s parent. Asa result, the buttons 
have both been made children of “Fade In 
Button Label.” This allows them to receive the 
messages that will activate/deactivate them si- 
multaneously. 


Fade In Button 
The messenger called “Fade In” on the Fade In 


button is configured to send the author message 
“fadeIn” to the scene on receipt of the “Execute” 
author message. (This message is generated by a 
messenger in the Radio Button behavior in re- 
sponse to the user clicking on the button.) 
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The “fadeIn” author message does two things. 
It activates the messenger on the sound element, 
which sends the command Unpause to the 
Festival.aiff, and it activates the sound fade 
modifier called “Fade to Full” on the sound 
element. This modifier causes the sound to 
increase, that is, to fade in. 


¢ Note: The initial state of the sound element is 
set to Pause in the sound element’s element info 
dialog. 


Sound Fade Modifier 

The percentage of volume to which the origi- 
nal sound file is to fade, and the duration of 

the sound’s fade is set from the dialog of the 

Fade to Full sound fade modifier. To see this di- 
alog (Figure 8.18), Double-click its icon on the 
Fade to Full sound element. 


Sound Fade Modifier 


j44} [Fade to Fun 


Enable ‘when Disable when: 


[radein [=| [Fsdeout | 


; Specifications 
Fade to: Duration: 


[i oo A) Joo 05.00 


Figure 8.18 The Fade to Full sound fade modifier 


Fade Out Button 

The programming of the Fade Out button is 
the same as that of the Fade In button, with 
the exception of the messenger that sends the 
author message “fadeOut.” 


The messenger called “Fade Out” on the Fade 
Out button is configured to send the message 
“fadeOut” to the scene on receipt of the Exe- 
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cute message. (Again, this message is generated 
by modifiers in the Radio Button behavior in 
response to the user clicking on the button.) 
When received by the sound fade modifier 
called “Fade to Silence” on the sound element 
Festival.aiff, the sound fades away. 


To cause the sound to fade, the dialog of the 
Fade to Silence sound effect modifier has 
been configured to fade the sound out to 0, 
over a duration of 5 seconds. 


Volume Buttons 

Unlike the Fade In and Fade Out buttons, the 
Volume buttons are not programmed with a 
Radio Button behavior. Since clicking on one 
or the other increases or decreases the vol- 
ume of the sound incrementally, neither but- 
ton is simply off or on. As a result, the 
Standard Button behavior is used. 


In addition to controlling the selected or de- 
selected appearance of the volume button, 
the Execute message generated by the Stan- 
dard Button behavior in response to mouse 
actions triggers the messenger on the Volume 
Up or Volume Down button. Depending on 
the button selected, “increaseVol” or “de- 
creaseVol” is sent to the Festival.aiff, which in 
turn activates either the Increase Volume or De- 
crease Volume Miniscript. Figure 8.19 shows 
the script of the Increase Volume Miniscript. 


Volume is an inherent property of any sound 
file. Since the sound fade modifiers on the 
sound element may have altered this proper- 
ty, this script is designed to assesses its cur- 
rent value. If the percentage of the current 
volume of the sound is less than 90, it will be 
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SS Miniscript Modifier 


Execute When: 


freresevor =] 


I-- Increase Volume 
I-- This script increases the volume of this sound by 


|-- a factor or 10 percent Cif it is not already at 
I-- maxinnum). 


lif volume <= 90 then 
set volume to volume + 10 


Figure 8.19 The Increase Volume Miniscript 


increased by 10, bringing the volume of the 
sound file to its maximum possible value 


(100%). 


The Decrease Volume Miniscript on the De- 
crease Volume button also checks the volume 
of the sound. If the percentage of the current 
volume of the sound is greater than 10, it will 
be decreased by 10, bringing the volume of 

the sound file to its minimum possible value 


(0%). 


MODIFIER EXAMPLES 

Select “Modifier Examples” from the mExam- 
ples main menu to display a submenu (Figure 
8.20) that gives access to many simple exam- 
ples that demonstrate the use of each mTrop- 
olis modifier. 


Click on an item in the list to display the ex- 
ample. Each example has three buttons at the 
bottom of its scene: 


a 


Figure 8.20 The Modifier Examples submenu 


: 


= “ 
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¢ About this Modifier: Click and hold on 
this button to see a short description of the 
modifier being demonstrated. 


¢ About this Example: Click and hold on 
this button to see a short description of the 
current example. 


* Modifier Icon: Click and hold on the mod- 
ifier icon to see the configuration dialog for 
this modifier. 


SIMPLE PROJECTS 


Select “Simple Projects” from the mExamples 
main menu to display a submenu that gives 
access to some advanced mTropolis projects. 
The “Autonomous Behaviors” example uses 
behaviors to create portable programming 
that can be reapplied in the same project or 
saved in libraries for use in other projects. 
The “Character Interaction” example features 
user-controlled animations using pre-set mo- 
tion paths in “2.5D” space. These examples 
are described below. 


AUTONOMOUS BEHAVIORS 


This example is designed to illustrate author- 
ing that can be used and re-used on various me- 
dia elements. Once configured, the 
functionality of the behavior can be copied 
and reused in other locations in a project, or 
saved in a library for use in future projects. 


Description 
A butterfly and a bug appear between the pil- 
lars in a temple scene. The bug has been pro- 
grammed to crawl over the floor, and to 


squish when the user clicks on it. The butter- 
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fly is programmed to flutter in random direc- 
tions in the air. It has also been programmed 
to fly away when it detects the proximity of 
the user’s mouse cursor. To see the program- 
ming in action, run the project and try click- 
ing on the butterfly or the bug. 


The programming of these animations has 
been modularized so that the behavior of 
each may be easily copied and pasted onto 
other objects. In edit mode drag and drop the 
Bug behavior from the bug element to the but- 
terfly, and the Butterfly behavior from the 
butterfly to the bug. Run the project again 
and try clicking on either animation to see the 
effect. The bug will evade the user’s cursor, 
and when clicked on, the butterfly will 
squish. 


The Temple Scene 

Custom palettes created in other applications 
and saved as CLUT files may be linked to a 
mTropolis project and used in any scene via 
the color table modifier. In this project, the 
color table on the scene has been configured 
to display its graphic elements using Temple 
CLUT v.2.0 when the scene starts. 


Blue Bug.toon 

A behavior called “Bug” and a variable called 
“actualSize” on the bug animation determine 
the bug’s functionality. 


actualSize 

The point variable called “actualSize” on the 
bug animation contains the actual pixel size 
of the bug media file. This variable is used to 
restore the dimensions of the element if the 

bug is squished during runtime. 


8.36 mTropolis Examples 


Bu 

Within the behavior called “Bug” is an aliased 
graphic modifier called “Transparent Ink.” 
This modifier is used in both the bug and but- 
terfly animations to make the background 
transparent. 


Next in the Bug behavior are the following 
variables: 


changeOdds 
This integer variable defines the odds of the 
butterfly changing direction. 


directions 

This integer variable specifies the number of 
possible directions in which the bug may 
move. 


direction 

This integer variable contains the direction 
(in degrees) in which the bug currently 
moves. 


normalSpeed 

This integer variable contains the value that 
defines the normal speed of the bug’s move- 
ment. 


motion 
This Vector variable contains the angle and 
magnitude of motion of the bug. 


There is another behavior named “Bug Mo- 
tion” in the Bug behavior. 


Bug Motion 
This behavior contains all the programming per- 


taining the motion of the bug on the screen. 


Initialization 
The first modifier in “Bug Motion” is a Mini- 


script named “Initialization.” This is used to 
initialize the motion of the bug. 


Move 
The vector motion modifier called “Move” in 


the Bug Motion behavior is used in conjunction 
with the vector variable called “motion” to set 
the motion of the bug. 


Change Direction Timer 

This messenger sends a “Change Direction Test” 
author message to the element every 0.80 sec- 
onds. 


Change Direction Test 

To determine when to change the direction of 
the bug’s movement, on receipt of the author 
message “Change Direction” the Miniscript 
modifier called “Change Direction Test” uses 
the md (random) math function with the 
changeOdds integer variable. If the evaluated 
expression equals 1, the author message 
“Change Movement” is sent out, causing the 
Miniscript called “Change Movement” to set 
new direction variable values. The script of 
the Change Motion Miniscript is shown in 
Figure 8.21. 


Notice the use of named ranges within the 
Change Movement script in Figure 8.21. 


Named ranges allow the instructions of this 
script to be applied to any mToon with cel 
ranges named “Up,” “Down,” “Left,” and 
“Right.” 


¢ Note: Since Miniscript looks for the name of 
the range rather than specific cel numbers of 
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Miniscript Modifier 


Al [Eranse Movement] 


Execute When: 


Change Movement || ¥] 


Script 
|-- Set animation range 
lif direction = 1 then 
set range to Up 
lelse if direction = 2 then 
set range to Left 
lelse if direction = 3 then 
set range to Down 
jelse 
set range to Right 
jend if. 


-- Set Vector variable angle 
set motion.angle to direction * 360/directions 


Figure 8.21 The Change Movement Miniscript 
modifier 


the mToon, there may be any number of cels in 
a new range of the same name. 


The last item within the “Bug Motion” behavior 
is another behavior, called “Bounce Off Con- 
tainer Walls.” 


Bounce Off Container Walls Behavior 

This behavior contains a border detection 
messenger and a Miniscript modifier used to 
change the direction of the bug if it hits the 
walls of its parent container (i.e., in this case, 
the edges of the scene). 


Bounce Off Container Walls Messenger 

The border detection messenger in the be- 
havior (also called “Bounce Off Container 
Walls”) sends a “Reverse Direction” author 
message to the messenger’s parent, the be- 
havior called “Bounce Off Container Walls.” 


Reverse Direction 
The next modifier in the behavior Bounce Off 
Container Walls is a Miniscript called “Reverse 


Autonomous Behaviors 


Direction.” It responds to the author message 
“Reverse Direction” by doing the calculations 
necessary to reverse the direction of the but- 
terfly. 


The final behavior within the Bug behavior is 
named “Squishability.” This behavior con- 
tains the programming necessary to simulate 
the “squishing” of the bug. 


Squishability Behavior 

The first two modifiers in this behavior are 
variables. They are used to set the position of 
the element when it is squished, and to set 
the degree to which it is squished. 


squishPos 
This variable contains the position of the bug 
on the screen when it was squished. 


squishFactor 

Next in the behavior is a floating point vari- 
able named “squishFactor.” Its value affects 
the amount of the element’s squish. 


Initialization 

The next modifier is a Miniscript called “Ini- 
tialization.” It restores the size of the element 
to its proper size when the scene starts. 


Squish Messenger 

The messenger named “Squish” sends the au- 
thor message “Squish” on receipt of a Mouse 
Down message. 


Squish Miniscript 

Next is a Miniscript modifier named 
“Squish.” Its script takes care of changing the 
size of the element. Figure 8.22 shows the 
contents of the Squish Miniscript. 
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SS————" Miniscript Modifier 


iE when: 

= 
Script 

Iset squishedPos to position 

send “Pause” to element 

send "Stop Movement" to element 


jset height to height * squishFactor 
set width to width * 3/2 
set position to 4 


squishedPos.x , squishedPos.y + actualSize.y - height 


Figure 8.22 The Squish Miniscript modifier 


The last modifier in the Squish behavior is a 
sound modifier named “Squish.” It simply 
plays a sound on receipt of the “Squish” au- 
thor message sent by the Squish messenger 
when the user clicks on the bug animation. 


¢ Note: Using a messenger to send the “Squish” 
author message allows the author to easily 
change the message that squishes the targeted 
object. Programming the Squish behavior in 
this way also allows different kinds of modifi- 
ers to send the message as the result of different 
activities. For example, a collision messenger 
placed on the bug element could be configured 
to send the “Squish” author message. This mes- 
sage would be received by the Squish sound 
modifier and the Squish Miniscript when the 
bug collides with another element. 


Blue Butterfly.toon 

The programming for the Butterfly is the 
same as that of the Bug except that it contains 
an Evasion behavior rather than a Squishability 
behavior. 


Evasion Behavior 
The Evasion behavior increases the motion 


speed of the element when the mouse cursor 
is over the element. It contains a variable and 
two Miniscript modifiers. 


evasionSpeed 

This integer variable stores the magnitude for 
the accelerated speed of the element’s mo- 
tion. 


Evade 

The Miniscript called “Evade” sets the magni- 
tude of the motion variable to the value of the 
evasionSpeed variable on receipt of the 
Mouse Over message. 


Out of Danger 

This Miniscript sets the magnitude of the mo- 
tion variable back to its original speed (using 
the normalSpeed variable). 


CHARACTER INTERACTION 


The Character Interaction example features a 
user-controlled animation along pre-set motion 
paths in “2.5D” space. Also featured are 
mTropolis’ digital audio playback capabili- 
ties. 


Description 

In this example, the user can control the hop- 
ping behavior of a frog in a swamp. The frog 
can move in one of four directions. Pressing 
one of four numeric keys (1, 3, 7, and 9) deter- 
mines which direction the frog jumps. Three 
butterflies move about the screen, and the 
frog will eat them if he gets close enough. 
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Figure 8.23 The Character Interaction “Swamp” scene in edit mode 


Creating the Illusion of 3D Space 

The graphic elements of the project are 
placed in a specific layer order to create the il- 
lusion of three-dimensional space. 


The Swamp Background.pict linked to the 
scene is placed at the bottom of the layer or- 
der, behind all other graphic elements in the 
scene. As it is to appear on the background but 
behind the reeds, the Swamp Frog.toon frog 
is next in the layer order. To enhance the illu- 
sion of depth, the background of the reed 
graphic elements has been made transparent, 
allowing both the Swamp Frog and the 
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Swamp Background to appear through the 
reeds. 


To make the butterflies appear in the fore- 
ground fluttering above the frog and reeds, they 
have been given layer order numbers greater 
than all other graphic elements in the scene. The 
reed graphics are in two sections, at the bot- 
tom and the left of the scene. 


Since mTropolis’ default transparent color 
(white) appears on the frog’s skin, the frog 
was rendered on a blue background. This col- 
or was then chosen as the transparent color 
for the mToon. 
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The Frog Animation 

The programming of the frog behavior on the 
Swamp Frog.toon has been modularized into 
three other behaviors, called “Keyboard Con- 
trol? “Initialization,” and “Motion.” The en- 
capsulation of the frog’s functionality into 
separate parts makes the frog behavior easily 
changeable. For example, “Keyboard Con- 
trol” could be easily replaced with a behavior 
that allows the frog to be controlled with 
mouse actions rather than keyboard keys. 


Each of the three behaviors in “Frog Behav- 
ior” will be discussed in turn. 


Initialization Behavior 

This behavior sets certain attributes when the 
scene starts. The messenger called “Preload” 
uses the Preload Media command to load the 
Swamp Frog.toon into memory for maximum 
performance. 


A Start Point point variable stores the frog’s 
screen position at scene start. Two messengers, 
called “Set Start Position” and “Set End Position” 
return the frog to this position when the scene 
starts and ends. This ensures that a frog that 
has jumped off the screen is restored to its 
original position when the project is run 
again. 


Keyboard Control Behavior 
This behavior contains modifiers that send 


motion messages to the Swamp Frog.toon el- 
ement. The “Any Key Cancel Path Keyboard” 
messenger cancels the frog in the middle of a 
jump when any key is pressed, allowing the 


user to change the frog’s direction in mid flight. 


The other four keyboard messengers send di- 
rectional author messages (“Up Right,” “Up 
Left,” “Down Right,” “Down Left”) to the 
Swamp Frog.Toon.n.t. element as the result ofa 
numeric key press (9, 7, 3 and 1 respectively). 


Motion Behavior 

This behavior contains the modifiers that 
make the frog jump. Each modifier listens for 
the author messages that result from a user’s 
key press and responds by showing specific 
cels in the frog animation. In this way, the 
frog is moved along the points that make up 
various motion paths. 


The motion is canceled when the modifier re- 
ceives a “Cancel Path” author message, dis- 
cussed earlier. 


Detection of the Butterflies 

Using the Parent/Child Tool, an invisible ele- 
ment called “Sensor” has been attached to 
(made a child of) the frog element. This ele- 
ment has been configured with a behavior 
called “Hunting,” which allows it to detect the 
butterfly elements. Note that the element Sen- 
sor is smaller than the Swamp Frog.toon ele- 
ment to which it is attached, creating a more 
specific area of butterfly detection. 


Within the behavior called “Hunting” is a col- 
lision messenger that sends an “ID Request” au- 
thor message to the elements that are detected 
by the Sensor element. The butterfly elements 
are each programmed to respond to an “ID 
Request” author message by sending the au- 
thor message “Fly ID.” This message is broad- 
cast, and when it is received by the Sensor 
element, the first messenger in the Hunting 
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behavior sends out a “Get Eaten” author mes- 
sage, and the second messenger commands 
the “Croak.aiff” sound to play. When re- 
ceived by the butterfly element, “Get Eaten” 
causes the butterfly to disappear from the 
screen, 


To ensure that the butterfly that originates 
the “Fly ID” author message is sent the mes- 
sage “Get Eaten,” Source’s Parent is chosen as 
the destination for the Eat Fly messenger in 
the frog’s Hunting behavior. 


Note 


¢ When using the collision messenger to cre- 
ate action/reaction sequences between ele- 
ments use Source’s Parent as the recipient of 
the message to be sent. 


The Contents of the Butterfly Behavior 

Each of the butterflies in this project uses an 
aliased behavior called “Butterfly.” The behavior 
is modularized into two logical parts that are 
encapsulated into separate behaviors called 
“Random Motion” and “Life” The contents of 
each behavior are described below. 


Random Motion 

The “Random Motion” behavior in the Butter- 
fly behavior contains the programming nec- 
essary to move the butterfly around the 
screen on random motion paths. The first five 
modifiers in this behavior are variables whose 
values are accessed at different times by other 
modifiers in the behavior. 


changeOdds 
This integer variable defines the odds of the 
butterfly changing direction. 
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directions 
This integer variable specifies the number of 


possible directions (out of 360 degrees) in 
which the butterfly may move. 


direction 
This integer variable contains the direction 


(in degrees) in which the bug currently 
moves. 


normalSpeed 

This integer variable contains the value that 
defines the normal speed of the butterfly’s 
movement. 


motion 
This vector variable contains the angle and 
magnitude of motion of the butterfly. 


Initialization 

The Miniscript modifier called “Initialization” 
initializes the motion of the butterfly when 
the project begins. 


Move 

This vector motion modifier is used in conjunc- 
tion with the motion vector variable to specify 
the butterfly’s motion. 


The next modifier in the behavior is a timer 
messenger called “Change Direction Timer.” 


Change Direction Timer 

This messenger sends a “Change Direction 
Test” author message to the element every 
0.80 seconds. 


Change Direction Test 

To determine when to change the direction of 
the butterfly’s movement on receipt of 
Change Direction Test, the Miniscript modifier 
called “Change Direction Test” uses the rnd 
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(random) math function with the changeOdds 
integer variable. If the evaluated expression 
equals 1, the author message “Change Move- 
ment” is sent out, causing the Miniscript 
called “Change Movement” to set new motion 
and direction variable values. 


The last item within the Random Motion be- 
havior is another behavior called “Bounce Off 
Container Walls.” 


Bounce Off Container Walls Behavior 
This behavior contains a boundary detection 


messenger and a Miniscript modifier used to 
change the direction of the butterfly if it hits 
the walls of its parent container (i.e., in this 
case, the edges of the scene). 


Bounce Off Container Walls Messenger 

The boundary detection messenger in the be- 
havior (also called “Bounce Off Container 
Walls”) sends a “Reverse Direction” author 
message to the messenger’s parent, the be- 
havior called “Bounce Off Container Walls.” 


Reverse Direction 
Next in the behavior Bounce Off Container 


Walls is a Miniscript called “Reverse Direction.” 
It responds to the author message “Reverse 
Direction” by doing the calculations neces- 
sary to reverse the direction of the butterfly. 


Life 

The next behavior within the behavior called 
“Butterfly” is called “Life.” It contains two 
messengers that communicate with the frog 
animation. The first messenger called “ID” 
functions simply by sending a “Fly ID” author 


message whenever it receives an “ID Request” 
author message. 


Get Eaten 

The next messenger is named “Get Eaten” and 
it sends acommand to the butterfly to Stop on 
receipt of the “Get Eaten” author message. 


Transparent Ink (White BG) 

The last modifier in the “Butterfly” behavior is 
named “Transparent Ink (White BG).” It is 
used to make the white background of an el- 
ement transparent. As it is used on other but- 
terflies in the project this graphic modifier 
has been aliased. 


Adding the Swamp Sound 

The ambient sound in this project is created 
by looping the playback of an AIFF sound 
file. The “Frogs Background.aiff” has been 
placed on the scene and configured to loop by 
checking the Loop check box in its element info 
dialog. 


Preload 
An aliased messenger named “Preload” has 


been placed on the Sound element. It simply 
sends a Preload Media command to the ele- 
ment on Scene Started. 


* Note: Sound elements and their modifiers are 
not visible in the layout view. Switch to the 
structure view to see the sound element and its 
messenger in the Swamp Background scene. 


Character Interaction 
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